On Saturday 01 July 2006 04:35, Matthias Andree wrote:
> Pat Lashley <[EMAIL PROTECTED]> writes:
>
> > BUT, that said, the safest and most portable coding practice would be:
> >
> >// The C standard does not require malloc(0) to return NULL;
> >// but whatever it returns MUST NOT b
On Fri, 30-Jun-2006 at 12:15:21 -0400, Pat Lashley wrote:
> >I went wandering through the C Working Group archives for the heck of
> >it, and apparently a lot of people were confused over this, thinking
> >either as you did or that "unique" meant it would a value unique to
> >the usage of malloc(0)
On Sat, 01-Jul-2006 at 10:35:47 +0200, Matthias Andree wrote:
> Pat Lashley <[EMAIL PROTECTED]> writes:
>
> > BUT, that said, the safest and most portable coding practice would be:
> >
> >// The C standard does not require malloc(0) to return NULL;
> >// but whatever it returns MUS
Pat Lashley <[EMAIL PROTECTED]> writes:
> BUT, that said, the safest and most portable coding practice would be:
>
>// The C standard does not require malloc(0) to return NULL;
>// but whatever it returns MUST NOT be dereferenced.
>ptr = ( size == 0 ) ? NULL : malloc( size
> No, sir. Operator precedence: assign first, and then compare, thus the
> comparison will always be true (else you'd be comparing to undefined
> values, which isn't any better). You might as well write:
>
> foo = malloc(0);
> /* make noise */
Ok, just for having it done:
if (foo == (
I went wandering through the C Working Group archives for the heck of
it, and apparently a lot of people were confused over this, thinking
either as you did or that "unique" meant it would a value unique to
the usage of malloc(0). It's been clarified recently (and will be in
the next revision of
On Fri, Jun 30, 2006 at 06:59:37AM +0200, Johannes Weiner wrote:
> Hi,
>
> On Thu, Jun 29, 2006 at 07:29:16PM +0200, Matthias Andree wrote:
> > No, sir. Operator precedence: assign first, and then compare, thus the
> > comparison will always be true (else you'd be comparing to undefined
> > values
On Thu, 2006-Jun-29 15:09:23 -0700, Randall Hyde wrote:
>>How about feeding the C source through the preprocessor, stripping out
>>the #line directives, compiling it and posting the exact gcc error and
>>source context.
>
>Okay, I'll try that when I get home. But I was kind of under the
>impression
Hi,
On Thu, Jun 29, 2006 at 07:29:16PM +0200, Matthias Andree wrote:
> No, sir. Operator precedence: assign first, and then compare, thus the
> comparison will always be true (else you'd be comparing to undefined
> values, which isn't any better). You might as well write:
>
> foo = malloc(0);
>
On Thu, 29 Jun 2006, Harti Brandt wrote:
> Operator precedence is just for parsing, not for evaluation. The
> compiler may well first evaluate the foo on the right side of the == (by
> fetching it) and then go an call malloc and assign foo.
Right, thanks for reminding me. I don't usually write
-Original Message-
>From: Thomas David Rivers <[EMAIL PROTECTED]>
>Sent: Jun 29, 2006 3:17 AM
>To: freebsd-hackers@freebsd.org, [EMAIL PROTECTED]
>Subject: Re: FLEX, was Re: Return value of malloc(0)
>
>"Randall Hyde" <[EMAIL PROTECTED]>
>&g
-Original Message-
>
>How about feeding the C source through the preprocessor, stripping out
>the #line directives, compiling it and posting the exact gcc error and
>source context.
Okay, I'll try that when I get home. But I was kind of under the impression
that *GCC* runs the preproces
Pat Lashley <[EMAIL PROTECTED]> writes:
>> On Thu, Jun 29, 2006 at 11:44:23AM -0400, Pat Lashley wrote:
>> > No, our implementation is NOT legal. We always return the SAME value. To
>> > be legal, we should not return that value again unless it has been
>> > free()-ed.
>>
>> It is legal due to b
On Thu, Jun 29, 2006 at 11:44:23AM -0400, Pat Lashley wrote:
> No, our implementation is NOT legal. We always return the SAME value. To
> be legal, we should not return that value again unless it has been
> free()-ed.
It is legal due to brain damaged definition of implementation defined
behavio
On Thu, Jun 29, 2006 at 11:44:23AM -0400, Pat Lashley wrote:
> >The C Standard says the following about malloc(0):
> >
> > If the size of the space requested is zero, the behavior is
> > implementation-defined: either a null pointer is returned, or the
> > behavior is as if the size were some no
On Thu, 29 Jun 2006, Matthias Andree wrote:
MA>Johannes Weiner <[EMAIL PROTECTED]> writes:
MA>
MA>> On Thu, Jun 29, 2006 at 06:09:37PM +0200, Matthias Andree wrote:
MA>>
MA>>> The value returned from malloc(0) must not be dereferenced whatever it
MA>>> was. It was 0x800, which doesn't count as "fa
Johannes Weiner <[EMAIL PROTECTED]> writes:
> On Thu, Jun 29, 2006 at 06:09:37PM +0200, Matthias Andree wrote:
>
>> The value returned from malloc(0) must not be dereferenced whatever it
>> was. It was 0x800, which doesn't count as "failure".
>
> But this would be appropriate for catching the erro
On Thu, Jun 29, 2006 at 11:44:23AM -0400, Pat Lashley wrote:
> No, our implementation is NOT legal. We always return the SAME value. To
> be legal, we should not return that value again unless it has been
> free()-ed.
It is legal due to brain damaged definition of implementation defined
behavi
On Thu, 29 Jun 2006, Johannes Weiner wrote:
JW>On Thu, Jun 29, 2006 at 06:09:37PM +0200, Matthias Andree wrote:
JW>
JW>> The value returned from malloc(0) must not be dereferenced whatever it
JW>> was. It was 0x800, which doesn't count as "failure".
JW>
JW>But this would be appropriate for catchin
On Thu, Jun 29, 2006 at 06:09:37PM +0200, Matthias Andree wrote:
> The value returned from malloc(0) must not be dereferenced whatever it
> was. It was 0x800, which doesn't count as "failure".
But this would be appropriate for catching the error:
if ((foo = malloc(0)) == foo)
/* make noi
Johannes Weiner <[EMAIL PROTECTED]> writes:
> Hi,
>
> On Wed, Jun 28, 2006 at 08:10:45PM +0200, Andre Albsmeier wrote:
>> "If you use malloc(0) and are crazy enough to access the 'allocated'
>> memory we give you a SIGSEV to show you how dumb you are :-)".
>
> They should check the return value of
The C Standard says the following about malloc(0):
If the size of the space requested is zero, the behavior is
implementation-defined: either a null pointer is returned, or the
behavior is as if the size were some nonzero value, except that the
returned pointer shall not be used to access
On Wed, 28-Jun-2006 at 16:19:35 -0400, Lowell Gilbert wrote:
> Andre Albsmeier <[EMAIL PROTECTED]> writes:
>
> >
> > The manpage makes me think that when malloc is called with 0
> > as argument (and no V-flag had been set) the pointer it returns
> > can actually be used (as a pointer to the so-cal
"Randall Hyde" <[EMAIL PROTECTED]>
>
> BTW, if anyone is intrested in the full FLEX source, it's part of the HLA
> (High Level Assembler) source package found here:
>
>
> http://webster.cs.ucr.edu/AsmTools/HLA/HLAv1.84/hlasrc.zip
>
Just wondering if those guys knew that IBM calls their mainfra
On Wed, 2006-Jun-28 22:40:45 -0700, Randall Hyde wrote:
>I seriously doubt seeing the code will do much good.
>Here's the offending line:
>
> YY_INPUT( (&yy_current_buffer->yy_ch_buf[number_to_move]),
> yy_n_chars, num_to_read );
How about feeding the C source through the preprocessor, strippi
On Wed, Jun 28, 2006 at 10:40:45PM -0700, Randall Hyde wrote:
> > >
> >
> > Without seeing the code or the actual error message, I'm
> > guessing the answer is 42. Perhaps, some detail might
> > be appropriate.
>
> I seriously doubt seeing the code will do much good.
> Here's the offending line:
Hi,
On Wed, Jun 28, 2006 at 08:10:45PM +0200, Andre Albsmeier wrote:
> "If you use malloc(0) and are crazy enough to access the 'allocated'
> memory we give you a SIGSEV to show you how dumb you are :-)".
They should check the return value of malloc() in any case for
successful allocation.. shoul
> >
>
> Without seeing the code or the actual error message, I'm
> guessing the answer is 42. Perhaps, some detail might
> be appropriate.
I seriously doubt seeing the code will do much good.
Here's the offending line:
YY_INPUT( (&yy_current_buffer->yy_ch_buf[number_to_move]),
yy_n_chars,
- Original Message -
From: "Steve Kargl" <[EMAIL PROTECTED]>
To: "Randall Hyde" <[EMAIL PROTECTED]>
Cc:
Sent: Wednesday, June 28, 2006 10:10 PM
Subject: Re: Return value of malloc(0)
> On Wed, Jun 28, 2006 at 06:41:05PM -0700, Randall Hyde wrote:
&g
On Wed, Jun 28, 2006 at 06:41:05PM -0700, Randall Hyde wrote:
> Hi All,
> I'm trying to port my compiler from Linux to freeBSD. It looked like a
> simple job up to the point I ran my flex code through FLEX on freeBSD. When
> GCC processes lex.yy.c I get a complaint about an illegal numeric constant
Hi All,
I'm trying to port my compiler from Linux to freeBSD. It looked like a
simple job up to the point I ran my flex code through FLEX on freeBSD. When
GCC processes lex.yy.c I get a complaint about an illegal numeric constant
in yy_get_next_buffer, which is all FLEX generated (or prewritten) co
On Wed, Jun 28, 2006 at 08:10:45PM +0200, Andre Albsmeier wrote:
> (Now malloc returns NULL and firefox doesn't interpret the
> result as a pointer to some allocated memory and therefore
> doesn't use it).
Return NULL for malloc(0) is one of two possible implementations. The
other behaviour is to
On Wed, Jun 28, 2006 at 08:10:45PM +0200, Andre Albsmeier wrote:
> There is a nice extension for firefox called prefbar. However,
> newer versions of prefbar (>=3.3) make firefox die with SIGSEGV,
> see http://bugzilla.mozdev.org/show_bug.cgi?id=13809 for details.
> The crash happens in libgklayout
Andre Albsmeier <[EMAIL PROTECTED]> writes:
>
> The manpage makes me think that when malloc is called with 0
> as argument (and no V-flag had been set) the pointer it returns
> can actually be used (as a pointer to the so-called "minimal
> allocation"). It seems, that firefox "thinks" the same way
There is a nice extension for firefox called prefbar. However,
newer versions of prefbar (>=3.3) make firefox die with SIGSEGV,
see http://bugzilla.mozdev.org/show_bug.cgi?id=13809 for details.
The crash happens in libgklayout.so:
Program received signal SIGSEGV, Segmentation fault.
[Switching to
35 matches
Mail list logo
