Project Home
Project Home		 Documents
Documents		 Wiki
Wiki		 Discussion Forums
Discussions		 Project Information
Project Info
QNX Operating System/Discussion/OSTech/Re: alloca/List of Posts
Forum Topic - Re: alloca: (6 Items)
   
Update
Aleksandar Ristovski(deleted)
07/06/2009 3:10 PM
post33210
Re: alloca   
Any thoughts?

Aleksandar Ristovski wrote:
> Hello,
> 
> Current definition of alloca creates problems in code like this:
> 
>   char *str = strcpy (alloca (strlen (command_str) + 1), command_str);
> 
> Compiler generates error:
> 
>  error: null argument where non-null required (argument 1)
> 
> 
> Why did we define alloca the way we did?
> 
> If there is no particular reason, then would something like this patch 
> (attached) make sense?
> 
> (Disclaimer: this is not patch submission, but rather an illustration - 
> I don't know what would be the right way to specify always_inline 
> attribute or inline modifier to make all supported compilers happy).
> 
> 
> 
> Thanks,
> 
> 
> Aleksandar
>
Mario Charest
07/06/2009 3:26 PM
post33212
RE: alloca   

> -----Original Message-----
> From: Aleksandar Ristovski [mailto:community-noreply@qnx.com]
> Sent: July-06-09 3:10 PM
> To: ostech-core_os
> Subject: Re: alloca
> 
> Any thoughts?
> 
> Aleksandar Ristovski wrote:
> > Hello,
> >
> > Current definition of alloca creates problems in code like this:
> >
> >   char *str = strcpy (alloca (strlen (command_str) + 1),
> command_str);
> >
> > Compiler generates error:
> >
> >  error: null argument where non-null required (argument 1)


Wouldn't it be the definition of strcpy?  Alloca could return NULL and strcpy will crash if the argument is null. Seems 
to me like the error is deserved.  This code is broken, the return value of alloca should be checked, 

> >
> >
> > Why did we define alloca the way we did?
> >
> > If there is no particular reason, then would something like this
> patch
> > (attached) make sense?
> >
> > (Disclaimer: this is not patch submission, but rather an illustration
> -
> > I don't know what would be the right way to specify always_inline
> > attribute or inline modifier to make all supported compilers happy).
> >
> >
> >
> > Thanks,
> >
> >
> > Aleksandar
> >
> 
> 
> 
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post33210
>
Aleksandar Ristovski(deleted)
07/06/2009 4:14 PM
post33216
Re: alloca   
Mario Charest wrote:
> 
>> -----Original Message-----
>> From: Aleksandar Ristovski [mailto:community-noreply@qnx.com]
>> Sent: July-06-09 3:10 PM
>> To: ostech-core_os
>> Subject: Re: alloca
>>
>> Any thoughts?
>>
>> Aleksandar Ristovski wrote:
>>> Hello,
>>>
>>> Current definition of alloca creates problems in code like this:
>>>
>>>   char *str = strcpy (alloca (strlen (command_str) + 1),
>> command_str);
>>> Compiler generates error:
>>>
>>>  error: null argument where non-null required (argument 1)
> 
> 
> Wouldn't it be the definition of strcpy?  Alloca could return NULL and strcpy will crash if the argument is null. 
Seems to me like the error is deserved.  This code is broken, the return value of alloca should be checked, 

malloc can return NULL too, yet there will be no warnings here:

char *str = strcpy (malloc (strlen (command_str) + 1), 
command_str);

gcc doesn't really know if a function can return NULL or 
not, but it can 'see' if a value may get explicit NULL which 
is happening in our alloca case:

#define alloca(s) \
((void*)(((__ALLOCA_ALIGN(s)+128)<__stackavail())?_alloca(s):NULL))

So my question is still:

>>> Why did we define alloca the way we did?
>>>
>>> If there is no particular reason, then would something like this
>> patch
>>> (attached) make sense?
>>>
>>> (Disclaimer: this is not patch submission, but rather an illustration
>> -
>>> I don't know what would be the right way to specify always_inline
>>> attribute or inline modifier to make all supported compilers happy).
>>>
>>>
>>>
>>> Thanks,
>>>
>>>
>>> Aleksandar
>>>
>>
>>
>> _______________________________________________
>> OSTech
>> http://community.qnx.com/sf/go/post33210
>>
> 
> 
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post33212
>
David Sarrazin
07/06/2009 4:24 PM
post33218
RE: alloca   
 

> -----Original Message-----
> From: Aleksandar Ristovski [mailto:community-noreply@qnx.com] 
> Sent: July 6, 2009 4:15 PM
> To: ostech-core_os
> Subject: Re: alloca
> 
> Mario Charest wrote:
> > 
> >> -----Original Message-----
> >> From: Aleksandar Ristovski [mailto:community-noreply@qnx.com]
> >> Sent: July-06-09 3:10 PM
> >> To: ostech-core_os
> >> Subject: Re: alloca
> >>
> >> Any thoughts?
> >>
> >> Aleksandar Ristovski wrote:
> >>> Hello,
> >>>
> >>> Current definition of alloca creates problems in code like this:
> >>>
> >>>   char *str = strcpy (alloca (strlen (command_str) + 1),
> >> command_str);
> >>> Compiler generates error:
> >>>
> >>>  error: null argument where non-null required (argument 1)
> > 
> > 
> > Wouldn't it be the definition of strcpy?  Alloca could 
> return NULL and 
> > strcpy will crash if the argument is null. Seems to me like 
> the error 
> > is deserved.  This code is broken, the return value of 
> alloca should 
> > be checked,
> 
> malloc can return NULL too, yet there will be no warnings here:
> 
> char *str = strcpy (malloc (strlen (command_str) + 1), command_str);
> 
> gcc doesn't really know if a function can return NULL or not, 
> but it can 'see' if a value may get explicit NULL which is 
> happening in our alloca case:
> 
> #define alloca(s) \
> ((void*)(((__ALLOCA_ALIGN(s)+128)<__stackavail())?_alloca(s):NULL))
> 
> So my question is still:
> 
> >>> Why did we define alloca the way we did?

Since alloca() can determine ahead of time if the allocation will work
or not, it's better to define it so that the compiler will complain.
That way broken code can be fixed.


> >>>
> >>> If there is no particular reason, then would something like this
> >> patch
> >>> (attached) make sense?


I never saw the patch proposal, it doesn't look like it was attached.
Aleksandar Ristovski(deleted)
07/06/2009 4:58 PM
post33221
Re: alloca   
David Sarrazin wrote:
>  
> 
>> -----Original Message-----
>> From: Aleksandar Ristovski [mailto:community-noreply@qnx.com] 
>> Sent: July 6, 2009 4:15 PM
>> To: ostech-core_os
>> Subject: Re: alloca
>>
>> Mario Charest wrote:
>>>> -----Original Message-----
>>>> From: Aleksandar Ristovski [mailto:community-noreply@qnx.com]
>>>> Sent: July-06-09 3:10 PM
>>>> To: ostech-core_os
>>>> Subject: Re: alloca
>>>>
>>>> Any thoughts?
>>>>
>>>> Aleksandar Ristovski wrote:
>>>>> Hello,
>>>>>
>>>>> Current definition of alloca creates problems in code like this:
>>>>>
>>>>>   char *str = strcpy (alloca (strlen (command_str) + 1),
>>>> command_str);
>>>>> Compiler generates error:
>>>>>
>>>>>  error: null argument where non-null required (argument 1)
>>>
>>> Wouldn't it be the definition of strcpy?  Alloca could 
>> return NULL and 
>>> strcpy will crash if the argument is null. Seems to me like 
>> the error 
>>> is deserved.  This code is broken, the return value of 
>> alloca should 
>>> be checked,
>> malloc can return NULL too, yet there will be no warnings here:
>>
>> char *str = strcpy (malloc (strlen (command_str) + 1), command_str);
>>
>> gcc doesn't really know if a function can return NULL or not, 
>> but it can 'see' if a value may get explicit NULL which is 
>> happening in our alloca case:
>>
>> #define alloca(s) \
>> ((void*)(((__ALLOCA_ALIGN(s)+128)<__stackavail())?_alloca(s):NULL))
>>
>> So my question is still:
>>
>>>>> Why did we define alloca the way we did?
> 
> Since alloca() can determine ahead of time if the allocation will work
> or not, it's better to define it so that the compiler will complain.
> That way broken code can be fixed.


It is probably desirable to check for returned NULL, but it 
is not required.

I would like to know if this was the intention.


> 
> 
>>>>> If there is no particular reason, then would something like this
>>>> patch
>>>>> (attached) make sense?
> 
> 
> I never saw the patch proposal, it doesn't look like it was attached.

Interesting. My original post was not referenced when I 
replied to myself:
http://community/sf/discussion/do/listPosts/projects.core_os/discussion.newcode.topc8327

(Note: that is not official patch proposal, it's an 
illustration - I hacked it that way locally).
Mario Charest
07/06/2009 3:27 PM
post33213
RE: alloca   
Look at the caveats in the alloc documentation ;-)

> -----Original Message-----
> From: Aleksandar Ristovski [mailto:community-noreply@qnx.com]
> Sent: July-06-09 3:10 PM
> To: ostech-core_os
> Subject: Re: alloca
> 
> Any thoughts?
> 
> Aleksandar Ristovski wrote:
> > Hello,
> >
> > Current definition of alloca creates problems in code like this:
> >
> >   char *str = strcpy (alloca (strlen (command_str) + 1),
> command_str);
> >
> > Compiler generates error:
> >
> >  error: null argument where non-null required (argument 1)
> >
> >
> > Why did we define alloca the way we did?
> >
> > If there is no particular reason, then would something like this
> patch
> > (attached) make sense?
> >
> > (Disclaimer: this is not patch submission, but rather an illustration
> -
> > I don't know what would be the right way to specify always_inline
> > attribute or inline modifier to make all supported compilers happy).
> >
> >
> >
> > Thanks,
> >
> >
> > Aleksandar
> >
> 
> 
> 
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post33210
>

Return


  A subsidiary of BlackBerry             All content ©2004-2013, QNX Software Systems