twitter: comp.lang.c - 25 new messages in 11 topics

comp.lang.c
http://groups.google.com/group/comp.lang.c?hl=en

comp.lang.c@googlegroups.com

Today's topics:

* Has thought been given given to a cleaned up C? Possibly called C+. - 1
messages, 1 author
http://groups.google.com/group/comp.lang.c/t/5954dc70a43f9f8e?hl=en
* Got stuck with quicksort code from the "Unleashed C". - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/0fb91f93b991c210?hl=en
* Correct way to write a wrapper for C functions that accept/return strings -
6 messages, 3 authors
http://groups.google.com/group/comp.lang.c/t/a933ecd78edafba1?hl=en
* Stylistic questions on UNIX C coding. - 5 messages, 3 authors
http://groups.google.com/group/comp.lang.c/t/51d2b24a60d73f18?hl=en
* typedef vs. #define - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/0613de840cefded9?hl=en
* ANNOUNCE: WinGDB - debugging with GDB under Visual Studio - 2 messages, 2
authors
http://groups.google.com/group/comp.lang.c/t/caa9b97bbee41cd4?hl=en
* Inorder Traversal - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/0691f3702d4d5606?hl=en
* Discount Wholesale Chanel shoes, LV shoes, Gucci shoes, Prada shoes etc
paypal payment free shipping (www.vipchinatrade.com) - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/2f8e830e9162910b?hl=en
* float point arithmetic a-a != 0.0 - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/9aebd187bdd10c51?hl=en
* Godaddy promo codes 2010 - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/993351ba5cf14089?hl=en
* question about macro? - 4 messages, 4 authors
http://groups.google.com/group/comp.lang.c/t/78ed6f536b032cfc?hl=en

==============================================================================
TOPIC: Has thought been given given to a cleaned up C? Possibly called C+.
http://groups.google.com/group/comp.lang.c/t/5954dc70a43f9f8e?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 9 2010 7:42 am
From: Dag-Erling Smørgrav

Ian Collins <ian-news@hotmail.com> writes:
> Dag-Erling Smørgrav <des@des.no> writes:
> > The implicit "struct" / "class" will get you in trouble [...]
> Why?

C keeps struct names in a separate namespace, C++ doesn't. The simplest
example I can come up with is this, which is legal in C but not in C++:

struct s { int i; };
typedef int s;

C++ has an exception for typedefing a struct or class under its own
name, i.e. this is fine in both languages:

typedef struct s { int i; } s;

DES
--
Dag-Erling Smørgrav - des@des.no
--
comp.lang.c.moderated - moderation address: clcm@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

==============================================================================
TOPIC: Got stuck with quicksort code from the "Unleashed C".
http://groups.google.com/group/comp.lang.c/t/0fb91f93b991c210?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 9 2010 7:38 am
From: Seebs

On 2010-03-09, Phred Phungus <Phred@example.invalid> wrote:
> I can't get COCKUS.C to compile, Dann:

> $ gcc -D_GNU_SOURCE -Wall -Wextra -c COCKUS.C -o cock.o
> gcc: error trying to exec 'cc1plus': execvp: Permission denied
> $ ls -l | grep COCK
> -rw-r--r-- 1 dan dan 7789 2010-03-09 01:06 COCKUS.C
> -rw-r--r-- 1 dan dan 7731 2000-02-24 15:23 COCKUS.C~
> $ gcc -D_GNU_SOURCE -Wall -Wextra a1.c -o out
> $ ./out

Your problem is that, unbeknownst to you, UNIX is being more case
sensitive than you expect. In particular, gcc assumes that a file with
a ".C" extension is C++, not C, and for some reason, your system's C++
compiler is busted.

> BTW, if Peter Seebach would look through this thread, he would see
> evidence of me reading C reference on a night in which his crystal ball
> erred on the side of sounding like my mormon ex-wife.

Yeah, but also evidence of you being characteristically unwilling to think
about what you see and draw conclusions from it. "cc1plus" sure sounds
like there's a "plus" somewhere in it, to me, and UNIX systems are typically
case-sensitive, so naming something in all caps, plus getting unexpected
behavior, suggests to me that trying it in lowercase might help. For
that matter:

$ man gcc
For any given input file, the file name suffix determines what kind of
compilation is done:
...
file.C
C++ source code which must be preprocessed. Note that in .cxx, the
last two letters must both be literally x. Likewise, .C refers to
a literal capital C.

All you have to do to find this is search for ".C" in the gcc man page.
This is not all that hard.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

==============================================================================
TOPIC: Correct way to write a wrapper for C functions that accept/return
strings
http://groups.google.com/group/comp.lang.c/t/a933ecd78edafba1?hl=en
==============================================================================

== 1 of 6 ==
Date: Tues, Mar 9 2010 7:53 am
From: Eli Osherovich

On Mar 9, 3:18 pm, Malcolm McLean <malcolm.mcle...@btinternet.com>
wrote:
> Phred Phungus wrote:
> > Eli Osherovich wrote:
> > > What is the correct way to write a wrapper for C functions that accept/
> > > return strings.
>
> > > For example
>
> > > void cfunc1(char* str)
> > > char * cfunc2(void)
>
> Acceting a string is easy. Just accept a char * or a const char * to a
> nul-terminated string.
>
> Returning strings you have to make a judgement call. Sometimes it is
> easier for caller to pass you a char * to a buffer which he controls,
> sometimes it is easier to return a char * containing allocated data.
> (Just rarely you want to retrn a char * to a static buffer). The fisrt
> method is likely to be faster and doesn't depend on malloc(), the
> second method is much less likely to allow a buffer overflow, and may
> the the only practical method if the length of the return string can't
> be predicted in advance.

May be I do not understand you correctly... but my impression is you
are talking about C not Fortran.

== 2 of 6 ==
Date: Tues, Mar 9 2010 8:47 am
From: "James Van Buskirk"

"Eli Osherovich" <eli.osherovich@gmail.com> wrote in message
news:3754018c-22d7-446f-95ed-f1053f08587c@g11g2000yqe.googlegroups.com...

> > > What is the correct way to write a wrapper for C functions that
> > > accept/
> > > return strings.

> > > For example

> > > void cfunc1(char* str)
> > > char * cfunc2(void)

> May be I do not understand you correctly... but my impression is you
> are talking about C not Fortran.

C:\gfortran\clf\c_interop>type c_example.c
#include <stdio.h>

char c[] = {'C',' ','t','e','s','t',' ','m','e','s','s','a','g','e','\0'};

void cfunc1(char* str)
{
printf("%s\n", str);
}

char *cfunc2(void)
{
return c;
}

C:\gfortran\clf\c_interop>type c_interop.f90
module c_interop
implicit none
interface
subroutine cfunc1(str) bind(C,name='cfunc1')
use ISO_C_BINDING
implicit none
character(kind=C_CHAR) str(*)
end subroutine cfunc1
! gfortran doesn't allow the following. I think it should.
! subroutine cfunc1a(str) bind(C,name='cfunc1')
! use ISO_C_BINDING
! implicit none
! type(C_PTR), value :: str
! end subroutine cfunc1a
function cfunc2() bind(C,name='cfunc2')
use ISO_C_BINDING
implicit none
type(C_PTR) cfunc2
end function cfunc2
end interface
end module c_interop

program test
use ISO_C_BINDING
use c_interop
implicit none
character(len=10,kind=C_CHAR), target :: test_msg
character(kind=C_CHAR), pointer :: fp(:)
type(C_PTR) cp
integer i

test_msg = 'Testing'//achar(0)
call cfunc1(test_msg)
! call cfunc1a(C_LOC(test_msg(1:1)))
cp = cfunc2()
i = 1
do
call C_F_POINTER(cp,fp,[i])
if(fp(i) == achar(0)) exit
i = i+1
end do
call sub(fp,i-1)
contains
subroutine sub(p,j)
! I know the next line was wrong, but check out the error message you get
! character(kind=C_PTR) p(*)
character(kind=C_CHAR) p(*)
integer j
character(len=j) c

c = transfer(p(:j),c)
write(*,'(a)') c
end subroutine sub
end program test

C:\gfortran\clf\c_interop>gcc -Wall -c c_example.c

C:\gfortran\clf\c_interop>gfortran -Wall c_interop.f90
c_example.o -oc_interop

C:\gfortran\clf\c_interop>c_interop
Testing
C test message

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

== 3 of 6 ==
Date: Tues, Mar 9 2010 9:58 am
From: glen herrmannsfeldt

In comp.lang.fortran Eli Osherovich <eli.osherovich@gmail.com> wrote:
> On Mar 9, 3:18?pm, Malcolm McLean <malcolm.mcle...@btinternet.com>
> wrote:
>> Phred Phungus wrote:
>> > Eli Osherovich wrote:
>> > > What is the correct way to write a wrapper for C functions
>> > > that accept/return strings.

>> > > For example
>
>> > > void cfunc1(char* str)
>> > > char * cfunc2(void)

Do you mean a Fortran wrapper for the C routine, or a C wrapper,
with the above declaration, for a Fortran routine?

>> Acceting a string is easy. Just accept a char * or a
>> const char * to a> nul-terminated string.

>> Returning strings you have to make a judgement call. Sometimes it is
>> easier for caller to pass you a char * to a buffer which he controls,
>> sometimes it is easier to return a char * containing allocated data.
>> (Just rarely you want to retrn a char * to a static buffer). The fisrt
>> method is likely to be faster and doesn't depend on malloc(), the
>> second method is much less likely to allow a buffer overflow, and may
>> the the only practical method if the length of the return string can't
>> be predicted in advance.

The first and third are most commonly used by C library routines,
and by user written functions. C programmers hate to have to keep
track of memory malloc()ed by other routines.

The string tokenizer, strtok(), returns pointers into the string
supplied to it in the first call. ctime() returns a pointer to
a static buffer. strdup() returns a pointer from malloc().

> May be I do not understand you correctly... but my impression is you
> are talking about C not Fortran.

Well, you have to talk about C somewhere. As a C wrapper to a Fortran
function, you have to do what other C programs can use. As a wrapper
to a C funtion, you have to live with what the C function does.
The above three are pretty much the choices you have.

-- glen

== 4 of 6 ==
Date: Tues, Mar 9 2010 10:57 am
From: Eli Osherovich

On Mar 9, 6:47 pm, "James Van Buskirk" <not_va...@comcast.net> wrote:
[snip]

James, it works. Thank you.

I have some questions about assumed-size vs assumed-shape arrays, but
I should probably ask them in a separate thread.

Thanks.

== 5 of 6 ==
Date: Tues, Mar 9 2010 10:57 am
From: Eli Osherovich

On Mar 9, 7:58 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> In comp.lang.fortran Eli Osherovich <eli.osherov...@gmail.com> wrote:
>
> > On Mar 9, 3:18?pm, Malcolm McLean <malcolm.mcle...@btinternet.com>
> > wrote:
> >> Phred Phungus wrote:
> >> > Eli Osherovich wrote:
> >> > > What is the correct way to write a wrapper for C functions
> >> > > that accept/return strings.
> >> > > For example
>
> >> > > void cfunc1(char* str)
> >> > > char * cfunc2(void)
>
> Do you mean a Fortran wrapper for the C routine, or a C wrapper,
> with the above declaration, for a Fortran routine?
>
> >> Acceting a string is easy. Just accept a char * or a
> >> const char * to a> nul-terminated string.
> >> Returning strings you have to make a judgement call. Sometimes it is
> >> easier for caller to pass you a char * to a buffer which he controls,
> >> sometimes it is easier to return a char * containing allocated data.
> >> (Just rarely you want to retrn a char * to a static buffer). The fisrt
> >> method is likely to be faster and doesn't depend on malloc(), the
> >> second method is much less likely to allow a buffer overflow, and may
> >> the the only practical method if the length of the return string can't
> >> be predicted in advance.
>
> The first and third are most commonly used by C library routines,
> and by user written functions. C programmers hate to have to keep
> track of memory malloc()ed by other routines.
>
> The string tokenizer, strtok(), returns pointers into the string
> supplied to it in the first call. ctime() returns a pointer to
> a static buffer. strdup() returns a pointer from malloc().
>
> > May be I do not understand you correctly... but my impression is you
> > are talking about C not Fortran.
>
> Well, you have to talk about C somewhere. As a C wrapper to a Fortran
> function, you have to do what other C programs can use. As a wrapper
> to a C funtion, you have to live with what the C function does.
> The above three are pretty much the choices you have.
>
> -- glen

I want a Fortran wrapper for C functions whose prototypes were given
in the first message.

== 6 of 6 ==
Date: Tues, Mar 9 2010 11:39 am
From: glen herrmannsfeldt

In comp.lang.fortran Eli Osherovich <eli.osherovich@gmail.com> wrote:
> On Mar 9, 7:58?pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>> In comp.lang.fortran Eli Osherovich <eli.osherov...@gmail.com> wrote:
>> > On Mar 9, 3:18?pm, Malcolm McLean <malcolm.mcle...@btinternet.com>
(snip)
>> >> Returning strings you have to make a judgement call. Sometimes it is
>> >> easier for caller to pass you a char * to a buffer which he controls,
>> >> sometimes it is easier to return a char * containing allocated data.
>> >> (Just rarely you want to retrn a char * to a static buffer). The fisrt
>> >> method is likely to be faster and doesn't depend on malloc(), the
>> >> second method is much less likely to allow a buffer overflow, and may
>> >> the the only practical method if the length of the return string can't
>> >> be predicted in advance.

>> The first and third are most commonly used by C library routines,
>> and by user written functions. ?C programmers hate to have to keep
>> track of memory malloc()ed by other routines.
(snip)
>> > May be I do not understand you correctly... but my impression is you
>> > are talking about C not Fortran.

>> Well, you have to talk about C somewhere. ?As a C wrapper to a Fortran
>> function, you have to do what other C programs can use. ?As a wrapper
>> to a C funtion, you have to live with what the C function does.
>> The above three are pretty much the choices you have.

> I want a Fortran wrapper for C functions whose prototypes were given
> in the first message.

Where does the (char*) return value come from? Presumably one
of the sources indicated above.

The right answer is that they are of TYPE(C_PTR), but often that
isn't what you want.

You can, for example, pass an array of CHARACTER(C_CHAR) to a C
routine expecting a (char *) if you don't put VALUE on the interface.

You can't really do that for the return value, though.

If the C routine returns a pointer to static storage
(usually of known size), then the Fortran routine can return
CHARACTER*(size), which you copy from the returned C value.

If the C routine returns malloc()ed space, ALLOCATE an
appropriate sized CHARACTER variable, copy the value,
free() the pointer, and return. (That is, if functions can
return ALLOCATABLE CHARACTER variables.)

If the function returns a pointer into the input string, you
might return an integer offset. For example, the C library
routine strstr(), sometimes known as index(), returns a pointer
into the argument string. You can't really do that in Fortran,
but returning the difference between the two pointers makes sense.
(strstr() can also return NULL, which you have to consider separately.)
Unfortunately, subtracting TYPE(C_PTR) in Fortran isn't easy.

-- glen

==============================================================================
TOPIC: Stylistic questions on UNIX C coding.
http://groups.google.com/group/comp.lang.c/t/51d2b24a60d73f18?hl=en
==============================================================================

== 1 of 5 ==
Date: Tues, Mar 9 2010 7:47 am
From: Seebs

On 2010-03-09, Nick Keighley <nick_keighley_nospam@hotmail.com> wrote:
> could you stop snipping so greedily! I had to back up twenty messages
> to find the context.

Sorry!

>> Because he pronounces it as "x is not equal to y", and the subject of
>> that sentence is "x". "x" is the actor, the variable that is acting. "y"
>> is part of the prepositional phrase, it is static.
>
> This is C we're discussing, not English. It is folly to pretend that
> the
> rules of English apply to C.

> On 8 Mar, 20:07, Seebs <usenet-nos...@seebs.net> wrote:
>> On 2010-03-08, Nick Keighley <nick_keighley_nos...@hotmail.com> wrote:
>> > On 7 Mar, 22:14, Seebs <usenet-nos...@seebs.net> wrote:
>> >> It hasn't been, but if you can find a counterexample to the claim that
>> >> people generally distinguish between topic and comment, I'd love to see it.
>> > to be honest I just don't see this in normal english. People
>> > describing events often intersperse the interpreation of events or
>> > motivation with what happened.
>>
>> That has absolutely nothing to do with the distinction between topic and
>> comment.
> [...]
>> When someone says "the bear ate Bob", the bear is the topic, "ate bob" is
>> the comment.
>
> this is a definition of "comment" I hadn't heard before. And an odd
> one. Is it a technical term from linguistics or something?

Yes. And one which someone had recently pointed out in-thread.

> So "topic" is what I'd call "subject" and "comment" is some sort of
> "action"? A way to try and link psychology with OO programming?

Comment is what you're saying about the subject. Not really "action" -- more
"information". "The ball is red" is not telling you about something the ball
*does*, but giving you information about its qualities.

And there's a big difference between "The ball is red" and "The red thing is a
ball" in English.

>> So far as I know, everyone makes this distinction. While it's not a hard and
>> fast rule, it's nearly always the case that the focus of discussion is the
>> topic of the sentence, not the comment. Thus, "the bear ate Bob" is a
>> statement by someone who is trying to talk about the bear, while "Bob was
>> eaten by a bear" is a statement by someone who is trying to talk about Bob.
>>
>> They don't have quite the same semantics. One has the implication "and we
>> care about what the bear did", the other has the implication "and we care
>> about what happened to Bob".

> And how does this apply to

> if (3 == thingy)
> do_something_with (thingy);

In
x == y

It is most often the case that x is topic, y is comment. Which is to say,
we are comparing a thing we are interested (x) in to a value we aren't
particularly expecting to change (y) but which would tell us about it.

In general, if I have a loop:
while (x != y) {
}

two things are true:
1. I almost certainly expect x to change during the loop, and y not to
change during the loop. It's not a guarantee, but if you check all the
code out there, in books, in real world code, etcetera, you'll find that
it's true nearly all the time. The only exceptions are people writing
it "backwards" and cases where both are subject to change.
2. A future reader of my code is, as a result, more likely than not to
at least initially make that assumption.

Having that assumption change if, and only if, y is a constant, is extremely
surprising.

Now, if you ALWAYS wrote it the other way -- if you always wrote "max > i"
rather than "i < max", etcetera -- people would probably find it less
confusing. It's that the natural order is consistently used except in
one specialized case that makes it so surprising.

> I'm very dubious about any argument that uses (cod?) psychology to
> justify language choice (that way lies Perl!). Human beings (and, I
> think programmers) are very flexible in what they find lingusitically
> acceptable. I don't like 3 == thingy but I don't think it relates to
> my cortextual wiring.

I am in general skeptical of them, but the strength of the topic/comment
rule is manifest, and the large number of people who find it confusing
suggests that it really *is* confusing.

I would guess that, had early code not developed a convention, we might not
find it so confusing, but once the convention was established... Going
against it is like driving on the other side of the road because you've
become convinced that it is a technically superior choice.

== 2 of 5 ==
Date: Tues, Mar 9 2010 9:54 am
From: Rainer Weikusat

Keith Thompson <kst-u@mib.org> writes:
> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
> [...]
>> If you desire to address the point I was trying to make, feel free to
>> do so. These sideline battles are useless exercises.
>
> I was trying to address the point that (I thought) you were trying
> to make. Perhaps if you could restate the point more clearly,
> I could try again to respond to it.

I already restated my point in a somewhat more condensed way,

,----
| It is completely obvious from the difference of meaning of the code
| which was written down vs the part of the code which actually performs
| some sensible function. Spelled out, the condition means (assuming
| that x is also a variable of type size_t)
|
| x = i, i = i - 1, x != 0
|
| Since the loop is only supposed to run until the counter has reached
| the value zero, decrementing an i whose value is zero when the
| condition is checked for the last time is just a pointless contortion.
`----

You have again ignored this completely. Further, I posted an
explanation of the difference between this
postincrement-where-it-isn't-appropriate issue and you for loop:

,----
| since none of the increments which are supposed to be performed by
| the code quoted above are technically useless, meaning, what I
| called 'overstepping the loop counter' does not occur here.
`----

Because the test is basically while (i < N), i needs to be incremented
until i == N, while in order to test i != 0, no post-decrement down to
(unsigned)-1 needs to be performed. You still claim that both would be
identical while they are clearly not identical and anyone with sufficient
knowledge in C to understand the code at all can be expected to
understand the difference. Lastly, I specifically wrote (in the first
text whose content you have chosen to ignore) that I wouldn't be
writing about "optimizations issues", yet, you are trying to drag me
into a discussion of exactly that in the other posting.

Whatever your motivation for acting in this way might be, for as long
as you are basically attaching unrelated statements to random parts of
heavily redacted variants of texts I originally wrote, any attempt at
a 'discussion' is a waste of bandwidth.

== 3 of 5 ==
Date: Tues, Mar 9 2010 10:21 am
From: Seebs

On 2010-03-09, Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
> You have again ignored this completely.

I looked at it a bit, and it didn't seem to say much.

> Further, I posted an
> explanation of the difference between this
> postincrement-where-it-isn't-appropriate issue and you for loop:

> ,----
>| since none of the increments which are supposed to be performed by
>| the code quoted above are technically useless, meaning, what I
>| called 'overstepping the loop counter' does not occur here.
> `----

> Because the test is basically while (i < N), i needs to be incremented
> until i == N, while in order to test i != 0, no post-decrement down to
> (unsigned)-1 needs to be performed. You still claim that both would be
> identical while they are clearly not identical and anyone with sufficient
> knowledge in C to understand the code at all can be expected to
> understand the difference.

I think we've gotten to a point where we need a couple of code fragments
in view.

Could you show us the two tests you're comparing, which you say are not
identical, and which someone else apparently said were identical? Ideally,
a short loop using each to, say, print the numbers from 9 to 0 or something
like that.

== 4 of 5 ==
Date: Tues, Mar 9 2010 10:44 am
From: Rainer Weikusat

Seebs <usenet-nospam@seebs.net> writes:
> On 2010-03-09, Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>> You have again ignored this completely.
>
> I looked at it a bit, and it didn't seem to say much.

Cutting something away from a text and than making a summary statement
about what had been cut away is a standard tactic.

== 5 of 5 ==
Date: Tues, Mar 9 2010 12:45 pm
From: Keith Thompson

Rainer Weikusat <rweikusat@mssgmbh.com> writes:
[big snip]
> Whatever your motivation for acting in this way might be, for as long
> as you are basically attaching unrelated statements to random parts of
> heavily redacted variants of texts I originally wrote, any attempt at
> a 'discussion' is a waste of bandwidth.

I have been honestly trying to understand what you've been saying.
If you're unwilling either to help or to answer direct questions,
then yes, this is a waste of bandwidth.

Bye.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

==============================================================================
TOPIC: typedef vs. #define
http://groups.google.com/group/comp.lang.c/t/0613de840cefded9?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Mar 9 2010 7:48 am
From: Seebs

On 2010-03-09, Mark <mark_cruzNOTFORSPAM@hotmail.com> wrote:
> Looks quite ugly to me, I'd prefer 'typedef' these types, but perhaps I'm
> missing something?

The obvious thing would be the lack of a way to spell "iftypedef(uint32)".

== 2 of 2 ==
Date: Tues, Mar 9 2010 12:27 pm
From: ImpalerCore

On Mar 9, 3:04 am, "Mark" <mark_cruzNOTFORS...@hotmail.com> wrote:
> Hello
>
> are there any other pros to using #defined new types, except the one
> mentioned in C-FAQ 1.13? Quite often I see in chips SDKs things like these:
>
> #ifndef int8
> #define int8 char
>

twitter

Tuesday, March 9, 2010

comp.lang.c - 25 new messages in 11 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts