Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > C/C++ guidelines

Reply
Thread Tools

C/C++ guidelines

 
 
Phlip
Guest
Posts: n/a
 
      09-16-2007
Wade Ward wrote:

>> Yes, I've done this before...


> I think the common subset of c and c++ is empty, because if you do malloc
> then yikes and if you don't malloc, well that's not much of a program is
> it.


Actually I haven't done the Common Subset thing.

But (char*)malloc(..) is well-formed C++ (with appropriate substitution for
....). Don't sweat the details; portability is up to your compiler(s).

--
Phlip
http://www.oreilly.com/catalog/9780596510657/
"Test Driven Ajax (on Rails)"
assert_xpath, assert_javascript, & assert_ajax


 
Reply With Quote
 
 
 
 
CBFalconer
Guest
Posts: n/a
 
      09-16-2007
Karl Heinze wrote:
> "Alf P. Steinbach" <(E-Mail Removed)> wrote:
>
> > [...] in C you should not cast the result of malloc, because
> > doing that might introduce subtle errors [...]

>
> For example?


Failure to #include <stdlib.h> going undetected.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>



--
Posted via a free Usenet account from http://www.teranews.com

 
Reply With Quote
 
 
 
 
CBFalconer
Guest
Posts: n/a
 
      09-16-2007
Phlip wrote:
> Wade Ward wrote:
>
>>> Yes, I've done this before...

>
>> I think the common subset of c and c++ is empty, because if you
>> do malloc then yikes and if you don't malloc, well that's not
>> much of a program is it.

>
> Actually I haven't done the Common Subset thing.
>
> But (char*)malloc(..) is well-formed C++ (with appropriate
> substitution for ...). Don't sweat the details; portability is up
> to your compiler(s).


And it is execreble dangerous coding in C. The languages are
different. This is c.l.c, and c.l.c++ is a separate newsgroup
dealing with a separate language. F'ups set.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>


--
Posted via a free Usenet account from http://www.teranews.com

 
Reply With Quote
 
Wade Ward
Guest
Posts: n/a
 
      09-16-2007



"Phlip" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ...
> Robbie Marshall wrote:
>
>> I'm about to embark on a new project and for maximum portability we've
>> been asked to code it in the common subset of C and C++.

>
> For maximum portability, write unit tests for all your code. Then you can
> run the tests on each target platform.
>
> For _real_ portability (not just "tell our boss we are portable"
> portability), you could configure a test server on each target platform.
> Run the test suite each time you integrate, automatically on each
> platform. Configure them to e-mail all the developers if the tests break
> on any platform.
>
> Yes, I've done this before...

I think the common subset of c and c++ is empty, because if you do malloc
then yikes and if you don't malloc, well that's not much of a program is it.
--
Wade Ward
http://www.velocityreviews.com/forums/(E-Mail Removed)
'Wheat is for man.'
--Joseph Smith>


 
Reply With Quote
 
Flash Gordon
Guest
Posts: n/a
 
      09-16-2007
Ark Khasin wrote, On 16/09/07 02:40:
> Richard Tobin wrote:
>> In article <(E-Mail Removed)>,
>> Ian Collins <(E-Mail Removed)> wrote:
>>
>>>> I'm about to embark on a new project and for maximum portability we've
>>>> been asked to code it in the common subset of C and C++.

>>
>>> For maximum portability, code in C89.

>>
>> That's not enough: for example you need to avoid C++ keywords
>> ("namespace" is one I've run into).

>
> Is it safe to code in C89/90/94 (corrigenda) and compile, or better yet
> lint as C++ AND C?


No. Since some code which is well formed in both languages will do
different things in the two languages. We have has some such examples
posted in comp.lang.c in the past week.

> Is it the same labo[u]r as to to write in a common subset of British and
> American and other flavo[u]rs of English?


The common subset changes.
--
Flash Gordon
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      09-16-2007
Robbie Marshall <(E-Mail Removed)> writes:
> I'm about to embark on a new project and for maximum portability we've
> been asked to code it in the common subset of C and C++.
>
> Can anyone suggest any good documents that might help us? Lists of
> gotchas to avoid, that sort of thing?


Consider programming in C90 and making sure not to accidentally use a
C++ compiler. You can enforce this with:

#ifdef __cplusplus
#error "Use a C compiler, not a C++ compiler"
#endif

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Peter J. Holzer
Guest
Posts: n/a
 
      09-16-2007
On 2007-09-16 03:16, CBFalconer <(E-Mail Removed)> wrote:
> Phlip wrote:
>> Wade Ward wrote:
>>
>>>> Yes, I've done this before...

>>
>>> I think the common subset of c and c++ is empty, because if you
>>> do malloc then yikes and if you don't malloc, well that's not
>>> much of a program is it.

>>
>> Actually I haven't done the Common Subset thing.
>>
>> But (char*)malloc(..) is well-formed C++ (with appropriate
>> substitution for ...). Don't sweat the details; portability is up
>> to your compiler(s).

>
> And it is execreble dangerous coding in C.


Whether that's "execreble dangerous" depends on your compiler. If
malloc has been declared, it's not dangerous, merely superfluous and
ugly. If malloc hasn't been declared, a good compiler should complain
with or without the cast.

hp


--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | (E-Mail Removed) |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"
 
Reply With Quote
 
Peter J. Holzer
Guest
Posts: n/a
 
      09-16-2007
On 2007-09-16 01:36, Karl Heinze <nomail@invalid> wrote:
> On Sat, 15 Sep 2007 18:14:30 -0700, "Chris Thomasson"
><(E-Mail Removed)> wrote:
>> http://c-faq.com/malloc/mallocnocast.html
>>

> Thanx. Though I don't buy in that "argument".
>
> Consider:
>
> #include <stdio.h>
>
> int main(void)
> {
> char *p = (char *) malloc(10);
>
> return 0;
> }
>
> At least lcc-win32 DOES warn you: "Missing prototype for 'malloc'.
>
> Same with Pelles C: "Missing prototype for 'malloc'".
>
> Same with gcc: "implicit declaration of function 'malloc'".


Once upon a time most compilers didn't warn about missing prototypes but
they did warn about conversions from int to a pointer. In these days not
casting malloc was the most reliable way to catch a missing declaration
of malloc.

Today I would advise anybody who's using such a compiler to get a
better one.

> So _my_ "A:" is: There's NOTHING wrong with casting malloc's return
> value. (But don't forget to include <stdlib.h>, man!)


There is STILL something wrong with casting malloc's return value: It is
unnecessary and clutters up the code. Also it gets you into the bad
habit of inserting unnecessary casts which *will* hide subtle errors.

hp


--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | (E-Mail Removed) |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"
 
Reply With Quote
 
Joachim Schmitz
Guest
Posts: n/a
 
      09-16-2007
"Peter J. Holzer" <(E-Mail Removed)> schrieb im Newsbeitrag
news:(E-Mail Removed)...
> On 2007-09-16 03:16, CBFalconer <(E-Mail Removed)> wrote:
>> Phlip wrote:
>>> Wade Ward wrote:
>>>
>>>>> Yes, I've done this before...
>>>
>>>> I think the common subset of c and c++ is empty, because if you
>>>> do malloc then yikes and if you don't malloc, well that's not
>>>> much of a program is it.
>>>
>>> Actually I haven't done the Common Subset thing.
>>>
>>> But (char*)malloc(..) is well-formed C++ (with appropriate
>>> substitution for ...). Don't sweat the details; portability is up
>>> to your compiler(s).

>>
>> And it is execreble dangerous coding in C.

>
> Whether that's "execreble dangerous" depends on your compiler. If
> malloc has been declared, it's not dangerous, merely superfluous and
> ugly. If malloc hasn't been declared, a good compiler should complain
> with or without the cast.

a diagnostic is not required by the standared for an implicit declared
function
without the cast and in absence of a prototype the compiler has to assume
int. Assiging an int to a pointer ist a constraint violation (6.5.16.1-1)
and as such requires a diagnostic (5.1.1.3-1)

While indeed a good compiler might warn about the missing prototype, even a
not so good one has to warn about the incompatible types in assignement (if
not it's a bad and non-conforming one). The latter doesn't happen if there's
a cast, hence not using the cast is the safer bet.

Bye, Jojo


 
Reply With Quote
 
Joachim Schmitz
Guest
Posts: n/a
 
      09-16-2007
"Peter J. Holzer" <(E-Mail Removed)> schrieb im Newsbeitrag
news:(E-Mail Removed)...
> On 2007-09-16 01:36, Karl Heinze <nomail@invalid> wrote:
>> On Sat, 15 Sep 2007 18:14:30 -0700, "Chris Thomasson"
>><(E-Mail Removed)> wrote:
>>> http://c-faq.com/malloc/mallocnocast.html
>>>

>> Thanx. Though I don't buy in that "argument".
>>
>> Consider:
>>
>> #include <stdio.h>
>>
>> int main(void)
>> {
>> char *p = (char *) malloc(10);
>>
>> return 0;
>> }
>>
>> At least lcc-win32 DOES warn you: "Missing prototype for 'malloc'.
>>
>> Same with Pelles C: "Missing prototype for 'malloc'".
>>
>> Same with gcc: "implicit declaration of function 'malloc'".

>
> Once upon a time most compilers didn't warn about missing prototypes but
> they did warn about conversions from int to a pointer. In these days not
> casting malloc was the most reliable way to catch a missing declaration
> of malloc.

Because they are required to do diagnose the conversionm and free to do do
the same with the missing prototype

Bye, Jojo


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Case Gallery rules and Guidelines Silverstrand Case Modding 0 06-20-2005 11:38 PM
Portable Coding Guidelines? Roger VHDL 0 12-17-2004 07:33 PM
Code Guidelines JIT ASP .Net 2 11-02-2004 06:57 AM
Is WPS compatible with Smart client as defined in WISPr guidelines nsmurthy Wireless Networking 0 08-13-2004 10:23 AM
VHDL Coding Guidelines Francisco Camarero VHDL 1 07-08-2003 08:17 PM



Advertisments