Date: Fri, 16 May 2008 11:18:29 -0400 From: "Bob McConnell" <rvm@CBORD.com> To: <freebsd-questions@freebsd.org> Subject: RE: Unable to talk to tap(4) Message-ID: <FF8482A96323694490C194BABEAC24A002B84683@Email.cbord.com> In-Reply-To: <20080516161816.M20005@wojtek.tensor.gdynia.pl> References: <FF8482A96323694490C194BABEAC24A002B83B78@Email.cbord.com><20080514234101.P2316@wojtek.tensor.gdynia.pl><FF8482A96323694490C194BABEAC24A002B841D1@Email.cbord.com><20080516081903.333b342d@locust> <20080516161816.M20005@wojtek.tensor.gdynia.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
From: Wojciech Puchar
>>>>>> if (buffer = NULL) {
>>
>> if (buffer == NULL) {
>>
> anyway not using malloc is good habit :) but it should work anyway.
> try
The test after the malloc was the problem. I have been working in a
poorly designed scripting language for several months where the single
'=' is used for comparisons and didn't "see" the difference when I got
back into C. Setting a pointer to NULL should always cause an EFAULT.
Unfortunately, even 'gcc -Wall' didn't generate an appropriate warning
for it.
I only use malloc when I won't know how many buffers I need until run
time. In this case the application will count records in a configuration
file and malloc (1514 * count * 2) bytes, where count can range from 1
to 2000. That becomes an array of buffers, so I can pass just an index
or pointer between threads, usually through a mailbox or message queue.
It's a simple trick for message passing that I picked up years ago while
using the CTASK and XINU kernels.
Thanks for all the help,
Bob McConnell
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FF8482A96323694490C194BABEAC24A002B84683>