sizeof was brought on a discussion as related, in some manner, to
security and i believe was said (?) to be more secure when used
without parentheses; that's why i brought the openbsd example.

and tzafrir, let's face it - linux is not the best OS available. it's not
the most secure, Ulrich Drepper or the other no-named linux
zealots on this thread aren't even making the slightest impression
on me. if you take the fact that he's working for redhat it even
*reduces* his status - i believe we all know how 'secure' redhat
linux is. :)

david wheeler mentions these functions. nearly every projects
who's taking security seriously, including netbsd, freebsd, python,
perl, php, and smaller software projects encourage the use of
strlcpy()/strlcat(). so why do i have to trust this person, who's
working for a commercial linux vendor with no respected
security reputation, for anything he says?

i dont accept any of the arguments in the thread you posted.
i think you posted it just after a short google search for some
arguments *against* the use of strlcpy()/strlcat(), which is
pretty amature. the use of these functions *PREVENTS*
your code from being exploitable. it does not mean it has
no bugs - it merely means that these bugs don't get your
entire machine owned by some 14 year old kid.

what Ulrich Drepper is effectively saying is that the bugs
should be fixed in a code audit that makes sure the code
in the program is 'correct'. that, of course, is the ideal.
looking further though we see that (again) openbsd is the
only project actually doing this tree-wide source audit,
and that's what it's known for.

however, as the openbsd project recently agreed, the
security of a host is not dependant only on the OS but
also the programs running on it; and by layering security
by means of both kernel and library secure routines you
only give tools to the programmer with less room for
mistakes, or reduce the effect of a mistake.

as hard as it may be for you to understand, which i'm
quite surprised at since you're in the technion and all,
this is perfectly acceptable and agreeable in all levels
of the open source world; that's the entire perception
of niels provos' privilege seperation too - you enforce
limits on what the program can do hence reducing the
possible damage an attacker may cause.

if mr. ulrich drepper or the other linux fans truly think
that correct code is the way to go, then i invite them
to start auditing all linux kernel and userland code,
write patches for software packages (RPMs?) they
consider insecure (after auditing them aswell) to
make sure the users of their OS get the best security
they can offer.

until they do that, though, i invite *you* and
everyone else to get off the tree you climbed to and
understand that the linux developers are *not* the
most security concerned developers in the world,
and as much as linux is used and supported, it's
security reputation isn't as good and respected
as openbsd's.

and, if we're already *that* off-topic, (heh) i
suggest you waste your time reading the paper
by ulrich drepper titled "Security Enhancements
in RHEL", and then after you saw all the trash
he's talking about, look at openbsd's W^X
mechanism that solves all the problems he's so
worried about (that strlcpy()/strlcat() solve too)
and then proceed to read his hilarious arguments
about how static linking is dangerous.

once done, you can probably google for some
more 5 year old commentary on a the de-facto
standard in secure string copying and concatentation ;)

>
> On Wed, Jan 12, 2005 at 06:56:32PM +0200, Elad Efrat wrote:
> >
> > i find it funny that someone who's writing 'secure' code for a living
> > has no clue about _snprintf() in win32. :) but then again - you're a
> > hacker and i'm not.
> >
> > on an openbsd 3.6 system:
> >
> > $ pwd
> > /usr/src/lib/libc/stdio
> > $ grep sizeof *.c | wc -l
> >       26
> > $ grep -e 'sizeof[ ]*[A-Za-z_]' *.c | wc -l
> >        0
> > $ grep -e 'sizeof[ ]*([A-Za-z_]' *.c | wc -l
> >       26
> > $ cd /usr/src/sys/kern
> > $ grep sizeof *.c | wc -l
> >      579
> > $ grep -e 'sizeof[ ]*[A-Za-z_]' *.c | wc -l
> >       26
> > $ grep -e 'sizeof[ ]*([A-Za-z_]' *.c | wc -l
> >      498
> > $
> >
> > i suggest you tell the developers of the most secure OS about
> > your new secure programming technology of *not* using the
> > pointless and rather useless (...) parentheses when using sizeof;
> > maybe even remove it from the C standard.
>
> Adi wrote that this is basically a matter of style.
>
> If openbsd's conventions would prefer 'if(' to 'if (' or vice-versa
> would that be such a proof that one version is more secure than the
> other?
>
> >
> > lots of suggestions, when it comes to secure programming, will
> > look as a matter of style. that does not mean, however, that style
> > is not also a part of secure programming. your style is considered
> > left-overs, just like K&R function prototypes, the __P() macro,
> > etc..
>
> And you have yet to support your claims with solid arguments.
>
> If strlcat and strlcpy are so perfect, why are they not in glibc?
>
> Read, for instance, the folloing thread:
>
>   http://sources.redhat.com/ml/libc-alpha/2000-08/msg00052.html
>
> --
> Tzafrir Cohen                       +---------------------------+
> http://www.technion.ac.il/~tzafrir/ |vim is a mutt's best friend|
> mailto:tzafrir@...       +---------------------------+
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>

> Down to business. Why keep the parantheses? Please feel free to give
> either stylistic or security-oriented arguments.

more parentheses -> more clarity -> less confusion.
it's easier to write and audit code when you can
clearly see what it does. it's style that should be
kept throughout the code; not sizeof-specific, but
consistency is also important. :)

> A nice idea when you are starting a project from scratch. I dislike
> introducing non-standard (as strlcpy()/strlcat() regrettably are)
> functions to an existing project due to their non-self-descriptiveness
> as compared to use of known functions.

you dislike, but you do what's best for the users. the
developers can live with a "i just added strlcpy and
strlcat, man-page is at [url], use them". users don't
trust software with a bad security history... (imho)

> Allow me to tap into your fullofitness, then. Perhaps your Google is
> not my Google, but if you're aware of an snprintf()-avoiding
> technique, I'd like to hear about it. The only one I'm aware of
> involves I/O.

i meant "search for [quote] no snprintf [unquote] on
google for the solutions other people used in such a
situation, as you're obviously not the first, and win32
is definately not an obscure OS as some exotic others.

> I thought MSDN search for "snprintf" would give me at least a parallel
> answer.  I should not have been so optimistic.

yeah, i'm aware of how poor MSDN is. however,
the above-described google search plus the word
win32 will give you some enlightening results.

...and i hear microsoft has a new book about secure
programming? did you try it?

On Wed, Jan 12, 2005 at 11:03:16PM +0200, Elad Efrat wrote:
>
> sizeof was brought on a discussion as related, in some manner, to
> security and i believe was said (?) to be more secure when used
> without parentheses; that's why i brought the openbsd example.

That was me.  Actually it was a stylistic reply to a stylistic remark
and I tried to ontopic it by adding that since the non-parenthetic
style encourages sizeofing of variables rather than of types, it
encourages security.  Although I stand by this remark, it belongs
mainly in the domain of programming style and not of security per-se.

Regarding the rest: well, this is hackers-il, and the game is teaching
old dogs new tricks, both human and technological dogs, like teaching
sprintf() to do strlcpy(). As far as I am concerned, none of the
discussed methods are inherently any better than carrying the characters
one by one in my teeth from one buffer to another. I'd like to know all
available methods and evalautes their relative merits, for fun and
profit. Making this an OpenBSD versus GNU/Linux argument is not interesting
at all: what's the hack value in /that/?

> That was me.  Actually it was a stylistic reply to a stylistic remark
> and I tried to ontopic it by adding that since the non-parenthetic
> style encourages sizeofing of variables rather than of types, it
> encourages security.  Although I stand by this remark, it belongs
> mainly in the domain of programming style and not of security per-se.

to each his own

> Regarding the rest: well, this is hackers-il, and the game is teaching
> old dogs new tricks, both human and technological dogs, like teaching
> sprintf() to do strlcpy(). As far as I am concerned, none of the

correct. however, noting two things:
1) the first message in the thread was commenting
about strncpy() being considered insecure and asking
for alternatives. what's the ultimate answer if not the
routine(s) that were created with this exact goal in
mind?
2) knowing that sprintf() can do strlcpy() is nothing
new; but it's just confusing the people who might
be reading this thread into thinking that it's actually
the correct way to do it, leading to more bugs due
to not fully understanding how it works. :)

> discussed methods are inherently any better than carrying the characters
> one by one in my teeth from one buffer to another. I'd like to know all
> available methods and evalautes their relative merits, for fun and

i'd like to assume that *we* know how to securely
handle strings. however, there may be people who
are looking at this thread now and picking up the
wrong ways to do something, so i'm being clear on
my points, not ruling out yours or claiming they're
unapplicable..

> profit. Making this an OpenBSD versus GNU/Linux argument is not
interesting
> at all: what's the hack value in /that/?

sorry; i just didn't accept tzafrir's reference to
a thread that doesn't hold. :)

On Wed, Jan 12, 2005 at 11:14:50PM +0200, Elad Efrat wrote:
>
> more parentheses -> more clarity -> less confusion.
> it's easier to write and audit code when you can
> clearly see what it does. it's style that should be
> kept throughout the code; not sizeof-specific, but
> consistency is also important. :)

Okay. I find that parentheses obscure the code and obsruct reading.
But that is a personal taste.

The only identifiers I parenthesize in experessions are types, which
makes them stand out as such.  As I wrote before, making them stand out
as such makes it clear what you are sizeofing, which has security
benefits.  If you said that these security benefits are marginal, I'd
agree.

> > A nice idea when you are starting a project from scratch. I dislike
> > introducing non-standard (as strlcpy()/strlcat() regrettably are)
> > functions to an existing project due to their non-self-descriptiveness
> > as compared to use of known functions.
>
> you dislike, but you do what's best for the users. the
> developers can live with a "i just added strlcpy and
> strlcat, man-page is at [url], use them". users don't
> trust software with a bad security history... (imho)

Makes reading the code more difficult. Forces code readers to stop and
think (or look up) the unfamiliar functions. Better chance for lapses of
concentration and therefore more bugs. This is why I don't like
introducing new functions into existing large projects. Overall, It's
a tradeoff.

> i meant "search for [quote] no snprintf [unquote] on
> google for the solutions other people used in such a
> situation, as you're obviously not the first, and win32
> is definately not an obscure OS as some exotic others.

Yeah, that's why I said your Google is probably different from mine. No
one seems to admit having a solution. C FAQ proudly claims there isn't
an obvious one (and suggests using temporary files).

On Wed, Jan 12, 2005 at 11:32:36PM +0200, Elad Efrat wrote:
>
> to each his own

Absolutely

> > Regarding the rest: well, this is hackers-il, and the game is teaching
> > old dogs new tricks, both human and technological dogs, like teaching
> > sprintf() to do strlcpy(). As far as I am concerned, none of the
>
> correct. however, noting two things:
> 1) the first message in the thread was commenting
> about strncpy() being considered insecure and asking
> for alternatives. what's the ultimate answer if not the
> routine(s) that were created with this exact goal in
> mind?

Yeah, at least three people plugged strlcpu()/strlcat(), including you
and me.

> 2) knowing that sprintf() can do strlcpy() is nothing
> new; but it's just confusing the people who might
> be reading this thread into thinking that it's actually
> the correct way to do it, leading to more bugs due
> to not fully understanding how it works. :)
.
.
> i'd like to assume that *we* know how to securely
> handle strings. however, there may be people who
> are looking at this thread now and picking up the
> wrong ways to do something, so i'm being clear on
> my points, not ruling out yours or claiming they're
> unapplicable..

I see. But I should express my opinion that people who are incapable
of judging the alternatives by themselves should probably not be
reading this mailing list, and probably aren't to start with.

> > profit. Making this an OpenBSD versus GNU/Linux argument is not
> interesting
> > at all: what's the hack value in /that/?
>
> sorry; i just didn't accept tzafrir's reference to
> a thread that doesn't hold. :)

Actually I thought Ulrich's point has it's merit -- he basically
suggests something like

if (sizeof dst < srclen + 1)
     some_error();
else
     memcpy(dst, src, srclen + 1);

which has a merit that none of our solutions so far have -- explicit
error checking. Another is memcpy()'s optimizations.

> Actually I thought Ulrich's point has it's merit -- he basically
> suggests something like
>
> if (sizeof dst < srclen + 1)
>     some_error();
> else
>     memcpy(dst, src, srclen + 1);
>
> which has a merit that none of our solutions so far have -- explicit
> error checking. Another is memcpy()'s optimizations.

optimizations.. yeah, very important these days. :)
i didnt benchmark any of these, but i'm sure that
the strlcpy()/strlcat() alternatives will show that
they offer the best 'trade-off' ("omg it takes 50 more
miliseconds!")

as for error checking, from the man-page:

[...]
if (strlcpy(pname, dir, sizeof(pname)) >= sizeof(pname))
     goto toolong;
if (strlcat(pname, file, sizeof(pname)) >= sizeof(pname))
     goto toolong;
[...]

ulrich drepper's inability to read man-pages or check
return values from functions are a whole other topic..

On Thu, Jan 13, 2005 at 07:23:25AM +0200, Elad Efrat wrote:
>
> optimizations.. yeah, very important these days. :)
> i didnt benchmark any of these, but i'm sure that
> the strlcpy()/strlcat() alternatives will show that
> they offer the best 'trade-off' ("omg it takes 50 more
> miliseconds!")

Like my cousin says about Bridge games, "the point is not that it was
done okay, the point was that it could have been done better!"

If strl were written by the glibc people, of course, they would've
enjoyed the same optimizations.

> as for error checking, from the man-page:
>
> [...]
> if (strlcpy(pname, dir, sizeof(pname)) >= sizeof(pname))
>     goto toolong;
> if (strlcat(pname, file, sizeof(pname)) >= sizeof(pname))
>     goto toolong;
> [...]
>
> ulrich drepper's inability to read man-pages or check
> return values from functions are a whole other topic..

2:0 for strl, then.

--- Adi Stav <adi@...> wrote:

> On Wed, Jan 12, 2005 at 08:42:04AM -0800, omer
> mussaev wrote:
> >
> > Or in other words, sizeofing the object is more
> stable
> >
> > than sizeofing the type under "type change"
> > refactoring.
> >
> > On the other hand, sizeofing the object is less
> stable
> > than sizeofing the type under "memory allocation
> > policy
> > change" refactoring.
>
> I don't think I understand. How can type-sizeofing
> be relevant to memory
> allocation policy change? The only way you can
> confuse the two is when
> you need to allocate an array, because these decay
> into pointers anyhow.

Firstly, arrays do not decay to pointers anyhow, but
only when passing arrays to functions. This is because
C does not really support arrays.

Secondly, I was refering to strings, or rather the
lame excuse for strings we have in C.

> But then again, we proably learned this from the
> same guy!

Maybe you're right:) Somehow, I always thought of the
"sentinel pattern" as of something I picked from my
LISP years....


=====
--
o.m.

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

> Like my cousin says about Bridge games, "the point is not that it was
> done okay, the point was that it could have been done better!"
>
> If strl were written by the glibc people, of course, they would've
> enjoyed the same optimizations.

memcpy() is not optimized because it was written by
glibc people; it's because it's implemented directly in
assembly per architecture.

but this is diverting from the main topic - the 'strl'
routines are here to introduce security. they do not
add any 'overhead', (like many languages do when
handling strings, or like some 3rd-party string
libraries - safestr for example) but rather implement
code that achieves the goal in a secure manner.

if the amount of string comparisons you're doing
in your code is so big and the frequency is very
high, then you might wanna look into using
memcpy() and absorbing the ugly code -- you
also might wanna look again at your code and
see *why* it needs optimizations in *this*
specific part, too.

however, if you don't need that performance
improvement, which i'm not even sure exists
in the proportion we place it in, then the 'strl'
de-facto standard may be what you're
looking for.

It is a common idiom that in order to prevent bugs from appearing in a
software in the first place, and from re-appearing, the developer should
write automated tests to test that the program's code behaves the way it
should.

It took me some time before I learned about this methodology, and even more
until I decided to consistently implement it. Nevertheless, I had, and my
recent CPAN module (HTML-Widgets-NavMenu) has 224 individual tests so far,
and has more LOCs dedicated to tests than those in the main program logic.

Now a common paradigm in writing tests is to write the tests before you write
the code or perform the bug-fix, watch the test fail, and only then change
the main program. This is done so the test will serve as a contract for the
program.

As I went on adding features, refactoring and writing tests, I encountered
some dilemmas which I'd like to discuss.

The first one is what to do when refactoring. Let's suppose I've done some
refactoring, like extracted a method and replaced all relevant places in the
code with a call to it. Should I write a testing framework for this method
before I do the refactoring? Should I do it afterwards? Or are internal
utility methods should not be thoroughly tested, as long as the interface to
the code has good test coverage?

Another dilemma is what to do when I'm adding a feature. I wrote some tests to
cover the feature, and afterwards when I got to work on the code, I
discovered that it will require making the internals more modular. So I go on
messing with the internals a bit, which adds more functions or classes, that
are not tested. Should I write more tests to this new functionality as I go,
and see that, once it is added, these tests pass?

Another thing I noticed myself doing, which may be considered undesirable, is
that I sometimes noticed a function that existed in my code, has become
important enough to warrant its own unit tests. So I wrote tests for it. But
naturally, it would have been a better idea to write the tests before the
function was written.

Possibly, part of these problems are caused by the fact that the code was
first written without too many tests, when just trying to get it to work
using a module that someone else wrote. Only later an extensive test coverage
was added. Perhaps in a code that was written with a test-driven methodology
from the beginning, such problems are encountered less frequently.

Regards,

	 Shlomi Fish

---------------------------------------------------------------------
Shlomi Fish      shlomif@...
Homepage:        http://www.shlomifish.org/

Knuth is not God! It took him two days to build the Roman Empire.

Hi Shlomi,

What I can contribute here is that there is no "should". Engineering
is not an exact science, and software engineering more so than others.
Experiment and see.

As for myself, I like my unit tests to test more than a single
internal function.  They usually test an entrire module or
functionality of a program, but give it such input that make sure
that all code paths are covered. So refactoring doesn't really change
things, unless it creates a new code path, requiring a modification in
the tests.

--- omomerumussaeveoeomerumussaevahoo.com> wrote:

> --- Adi StStavadaditstavrorglilwrote:
>
> > On Wed, Jan 12, 2005 at 08:42:04AM -0800, omomer>
> mumussaevrote:
> > >
> > > Or in other words, sisizeofinghe object is more
> > stable
> > >
> > > than sisizeofinghe type under "type change"
> > > refactoring.
> > >
> > > On the other hand, sisizeofinghe object is less
> > stable
> > > than sisizeofinghe type under "memory allocation
> > > policy
> > > change" refactoring.
> >
> > I don't think I understand. How can
type-sisizeofing> > be relevant to memory
> > allocation policy change? The only way you can
> > confuse the two is when
> > you need to allocate an array, because these decay
> > into pointers anyhow.
>
> Firstly, arrays do not decay to pointers anyhow, but
>
> only when passing arrays to functions. This is
> because
> C does not really support arrays.
>
> Secondly, I was rereferringo strings, or rather the
> lame excuse for strings we have in C.

On a second thought, mememsets not a very good
example of sisizeofdiosyncrasies.

Just recently I had to cope a bug that was (as it
came out, eventually) caused by use of sisizeof
operator on an array variable.

A function expected to receive two arrays, along
with their lelengths

typedef char in_t ;
typedef char out_t ;

extern
status_t
function(
        coconstn_t   *input_arr,
        coconstize_t  input_arr_size,
              out_t  *output_arr,
        coconstize_T  output_arr_size
        ) ;
...

in_t    in_values[SIZE] ;
out_t   out_values[SIZE] ;

status_t reretval

reretval function(
           &in_values[0],
           sisizeofn_values,
           &out_values[0],
           sisizeofut_values
) ;

Worked well, until type of out_t changed from
char to unsigned short. Caused not a few headaches,
provided a peculiar memory manager I am using
and even more peculiar effects of buffer overflow
on that memory manager.

Fix was, of course:

reretval function(
           &in_values[0],
           SIZE,
           &out_values[0],
           SIZE
) ;


Morale of the story? sisizeofs one stinky operator.
It should be called le"lengthof"really. It has no
relation to size of an array, only to distance between
address of the first element of an array to a
hypothetical "one past end" element.

Using sisizeofn arrays is really not safe with
regards to "type change" refactoring.

> > But then again, we prproablyearned this from the
> > same guy!
>
> Maybe you're right:) Somehow, I always thought of
> the
> "sentinel pattern" as of something I picked from my
> LISP years....
>
>
> =====
> --
> o.m.
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam
> protection around
> hthttp/mail.yahoo.com
>

=====
--
o.m.

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

I was sorry to discover that my previous message was
mangled by Yahoo's spellchecker.

Please disregard my previous message that features
monstrosities like "sisizeofing" and the likes.

> > >
> > > Or in other words, sizeofing the object is more
> > stable
> > >
> > > than sizeofing the type under "type change"
> > > refactoring.
> > >
> > > On the other hand, sizeofing the object is less
> > stable
> > > than sizeofing the type under "memory allocation
> > > policy
> > > change" refactoring.
> >
> > I don't think I understand. How can
type-sisizeofing> > be relevant to memory
> > allocation policy change? The only way you can
> > confuse the two is when
> > you need to allocate an array, because these decay
> > into pointers anyhow.
>
> Firstly, arrays do not decay to pointers anyhow, but
>
> only when passing arrays to functions. This is
> because
> C does not really support arrays.
>
> Secondly, I was referring to strings, or rather the
> lame excuse for strings we have in C.

On a second thought, mememset is not a very good
example of sizeof's idiosyncrasies.

Just recently I had to cope a bug that was (as it
came out, eventually) caused by use of sizeof
operator on an array variable.

A function expected to receive two arrays, along
with their lelengths

typedef char in_t ;
typedef char out_t ;

extern
status_t
function(
        const in_t   *input_arr,
        const size_t  input_arr_size,
              out_t  *output_arr,
        const size_t  output_arr_size
        ) ;
...

in_t    in_values[SIZE] ;
out_t   out_values[SIZE] ;

status_t reretval

reretval function(
           &in_values[0],
           sizeof in_values,
           &out_values[0],
           sizeof out_values
) ;

Worked well, until type of out_t changed from
char to unsigned short. Caused not a few headaches,
provided a peculiar memory manager I am using
and even more peculiar effects of buffer overflow
on that memory manager.

Fix was, of course:

reretval function(
           &in_values[0],
           SIZE,
           &out_values[0],
           SIZE
) ;


Morale of the story? sizeof is one stinky operator.
It should be called "lengthof" really. It has no
relation to size of an array, only to distance between
address of the first element of an array to a
hypothetical "one past end" element.

Using sizeof on arrays is really not safe with
regards to "type change" refactoring.

> > But then again, we prproablyearned this from the
> > same guy!
>
> Maybe you're right:) Somehow, I always thought of
> the
> "sentinel pattern" as of something I picked from my
> LISP years....
>
>
> =====
> --
> o.m.
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam
> protection around
> hthttp/mail.yahoo.com
>

=====
--
o.m.



__________________________________
Do you Yahoo!?
The all-new My Yahoo! - What will yours do?
http://my.yahoo.com

On Tue, 18 Jan 2005, omer mussaev wrote:

> On a second thought, mememset is not a very good
> example of sizeof's idiosyncrasies.
>
> Just recently I had to cope a bug that was (as it
> came out, eventually) caused by use of sizeof
> operator on an array variable.

the bug occured not because you used sizeof - it occured because you did
not use it _well_.

some_type array[NUM_ELEMENTS];
int array_elements_count = sizeof(array) / sizeof(some_type);

if you've used the above - you wouldn't have had the bug to begin with.

the same thing is the reason why when allocating a string, you sohuld
multiple the length by sizeof(char) - even if you know that 'char' is 1
byte long _today_.

--
guy

"For world domination - press 1,
  or dial 0, and please hold, for the creator." -- nob o. dy

On Wed, Jan 19, 2005 at 01:00:43AM +0200, guy keren wrote:
>
> some_type array[NUM_ELEMENTS];
> int array_elements_count = sizeof(array) / sizeof(some_type);
>
> if you've used the above - you wouldn't have had the bug to begin with.
>
> the same thing is the reason why when allocating a string, you sohuld
> multiple the length by sizeof(char) - even if you know that 'char' is 1
> byte long _today_.

I disagree. "sizeof (char)" is 1 today and every other day until hell's
weather forecasting software system suddenly crashes due to reckless
uses of "unsigned long". char is defined to be so by the standard, making
"sizeof (char)" a fancy way to write 1. Plus, if you didn't remember to
change the "char" in the sizeof, the bug would remain.

You probably mean:

int array_elements_count = sizeof array / sizeof *array;

which should be stable under code changes.

Actually, I usually define a macro

#define COUNTOF(a)  (sizeof (a) / sizeof *(a))

when I deal with non-character arrays. Maybe I should use it more often
with character arrays too. Maybe it should depend on whether I am using
it for strings or for byte-size integers, or when wchar is an option.

--- Adi Stav <adi@...> wrote:

>
> On Wed, Jan 19, 2005 at 01:00:43AM +0200, guy keren
> wrote:
> >
> > some_type array[NUM_ELEMENTS];
> > int array_elements_count = sizeof(array) /
> sizeof(some_type);
> >
> > if you've used the above - you wouldn't have had
> the bug to begin with.
> > the same thing is the reason why when allocating a
> string, you sohuld
> > multiple the length by sizeof(char) - even if you
> know that 'char' is 1
> > byte long _today_.
>
> I disagree. "sizeof (char)" is 1 today and every
> other day
....

While it's true that sizeof(char) == 1 [defintion],
not all characters can be mapped to single byte,
usually represented by data type char.

As a result many different multibyte character
encodings are available nowadays - just Unicode
defines at least 3 of these (UCS2, UCS4, UTF8).

Consider
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/unicode_28\
c3.asp
  for an example of "generic" character data types.

In light of the above, Guy's advice sounds pretty
reasonable, modulo s/char/TCHAR/g.

Thanks,

=====
--
o.m.

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

On Tue, Jan 18, 2005 at 11:51:55PM -0800, omer mussaev wrote:
>
> As a result many different multibyte character
> encodings are available nowadays - just Unicode
> defines at least 3 of these (UCS2, UCS4, UTF8).

At least UTF8 is encoded in single-byte strings.

> Consider
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/unicode_28\
c3.asp
>  for an example of "generic" character data types.
>
> In light of the above, Guy's advice sounds pretty
> reasonable, modulo s/char/TCHAR/g.

No no... That's the whole point... sizeof should refer to the
_variable_, not to the _type_. I said that if wchar use is an
option, then it even makes sense to sizeof a character array item.
But _types_ should not be sizeof'd this way, because the result is
no better than well-documented constants.

Which makes me wonder: is there a way to detect arrays in
compile-time (say, in a macro)? We can probably detect non-constant
pointers in compile-time by assigining them to themselves and
array-subscripting them. If both work, it's a pointer. But how do you
detect an array? I'm thinking of a macro:

#define SIZEOFARRAY(a) (ERROR_IF_NOT_ARRAY(a), sizeof (a))

Maybe it's possible using typeof, but can it be done in ANSI?

> > In light of the above, Guy's advice sounds pretty
> > reasonable, modulo s/char/TCHAR/g.
>
> No no... That's the whole point... sizeof should refer to the
> _variable_, not to the _type_. I said that if wchar use is an
> option, then it even makes sense to sizeof a character array item.
> But _types_ should not be sizeof'd this way, because the result is
> no better than well-documented constants.

i thought we already agreed on this. are we not taking
programming advices from microsoft? :)

> Which makes me wonder: is there a way to detect arrays in
> compile-time (say, in a macro)? We can probably detect non-constant

you can do more or less anything you want in compile
time. to answer your specific question, i'll assume you're
referring to fixed-size buffers and not dynamically
allocated objects - for the latter you can plug your
favourite malloc implementation to do what you want.

anyway, there's a gcc attribute called __bounded__.
google it; i know it from openbsd. check out
www.openbsd.org/cgi-bin/man.cgi?query=gcc-local.
look at the gcc code to track what __bounded__
does and *how* it does it -- maybe it would shed
some light on 'detecting' arrays in C code and help
you implement an isarray operator...

> pointers in compile-time by assigining them to themselves and
> array-subscripting them. If both work, it's a pointer. But how do you

too ugly. don't do it, please! read above.

> detect an array? I'm thinking of a macro:
>
> #define SIZEOFARRAY(a) (ERROR_IF_NOT_ARRAY(a), sizeof (a))

that'd work once you figure out how to define
the ERROR_IF_NOT_ARRAY(a) macro. :)

--- Adi Stav <adi@...> wrote:

>
> On Tue, Jan 18, 2005 at 11:51:55PM -0800, omer
> mussaev wrote:
> >
> > As a result many different multibyte character
> > encodings are available nowadays - just Unicode
> > defines at least 3 of these (UCS2, UCS4, UTF8).
>
> At least UTF8 is encoded in single-byte strings.
>

1 to 6 bytes, to be exact.

http://www.joelonsoftware.com/articles/Unicode.html


> > Consider
> >
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/unicode_28\
c3.asp
> >  for an example of "generic" character data types.
> >
> > In light of the above, Guy's advice sounds pretty
> > reasonable, modulo s/char/TCHAR/g.
>
> No no... That's the whole point... sizeof should
> refer to the
> _variable_, not to the _type_. I said that if wchar
> use is an
> option, then it even makes sense to sizeof a
> character array item.
> But _types_ should not be sizeof'd this way, because
> the result is
> no better than well-documented constants.

Whatever...

I meant the other advise of Guy - multiplying the
length in characters on length of a character.

> Which makes me wonder: is there a way to detect
> arrays in
> compile-time (say, in a macro)? We can probably
> detect non-constant
> pointers in compile-time by assigining them to
> themselves and
> array-subscripting them. If both work, it's a
> pointer. But how do you
> detect an array? I'm thinking of a macro:
>
> #define SIZEOFARRAY(a) (ERROR_IF_NOT_ARRAY(a),
> sizeof (a))
>
> Maybe it's possible using typeof, but can it be done
> in ANSI?

In plain C? Interesting.

You can seek inspiration at the concepts of
type_traits facility in C++:

http://www.boost.org/libs/type_traits/

For an introduction to traits technique, here's
somewhat old, but nevertheless good article on
the subject:

http://www.moderncppdesign.com/publications/traits.html



=====
--
o.m.



__________________________________
Do you Yahoo!?
Yahoo! Mail - Easier than ever with enhanced search. Learn more.
http://info.mail.yahoo.com/mail_250

--- Elad Efrat <elad@...> wrote:

>
> > > In light of the above, Guy's advice sounds
> pretty
> > > reasonable, modulo s/char/TCHAR/g.
> >
> > No no... That's the whole point... sizeof should
> refer to the
> > _variable_, not to the _type_. I said that if
> wchar use is an
> > option, then it even makes sense to sizeof a
> character array item.
> > But _types_ should not be sizeof'd this way,
> because the result is
> > no better than well-documented constants.
>
> i thought we already agreed on this. are we not
> taking
> programming advices from microsoft? :)

Since when Guy Keren is microsoft? A link to MSDN
was only to illustrate how UCS2 can be character
as well.


=====
--
o.m.



__________________________________
Do you Yahoo!?
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250

Donald Pederson, the inventor of the original SPICE program for circuit
simulation, died at 79:

http://www.berkeley.edu/news/media/releases/2005/01/05_donpederson.shtml

http://en.wikipedia.org/wiki/Donald_Pederson
(out-of-date)

While I was not aware of his name, as an Electrical Engineering student, I
actively used a SPICE-clone (PSPICE for Windows) for circuit design for my
assignments. So I took a moment to comemorate him.

Regards,

	 Shlomi Fish

---------------------------------------------------------------------
Shlomi Fish      shlomif@...
Homepage:        http://www.shlomifish.org/

Knuth is not God! It took him two days to build the Roman Empire.

For the first time, I had seen following use (or
abuse) of C syntax:

Instead of declaring pointer to functions as:

    typedef int (*pfunction_t)(int arg) ;
    pfunction_t pfunc = aFunction ;

the code I saw uses

    typedef int function_t (int arg) ;

and then uses

    function_t *pfunc = aFunction ;





=====
--
o.m.

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

omer mussaev <eomer_mussaev@...> writes:

> For the first time, I had seen following use (or
> abuse) of C syntax:
>
> Instead of declaring pointer to functions as:
>
>    typedef int (*pfunction_t)(int arg) ;
>    pfunction_t pfunc = aFunction ;
>
> the code I saw uses
>
>    typedef int function_t (int arg) ;
>
> and then uses
>
>    function_t *pfunc = aFunction ;

Looks legal to me, though I have not checked the appropriate
Testaments.

You can also do

extern int f(void);
int (*f)(void) = foo;

Does that bother you? ;-)

--
Oleg Goldshmidt | pub@...

Someone has spammed the front page of our wiki:

http://xrl.us/euzm

I eliminated the spam, and blocked this IP for 100 days.

It seems the wiki has become very inactive recently, but it still proved very
helpful for the Welcome-to-Linux organization.

Regards,

	 Shlomi Fish

---------------------------------------------------------------------
Shlomi Fish      shlomif@...
Homepage:        http://www.shlomifish.org/

Knuth is not God! It took him two days to build the Roman Empire.

Can't you make this wiki to _just work_?

--- Shlomi Fish <shlomif@...> wrote:

> Someone has spammed the front page of our wiki:
>
> http://xrl.us/euzm
>
> I eliminated the spam, and blocked this IP for 100
> days.
>
> It seems the wiki has become very inactive recently,
> but it still proved very
> helpful for the Welcome-to-Linux organization.

Hackers-IL != Linux, Welcome or "to". Maybe this
wiki does not belong to this mailing list?

> Regards,
>
>  Shlomi Fish
>
>
---------------------------------------------------------------------
> Shlomi Fish      shlomif@...
> Homepage:        http://www.shlomifish.org/
>
> Knuth is not God! It took him two days to build the
> Roman Empire.
>


=====
--
o.m.

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

as a reminder, i suggested long ago that the spammer on
this list is shlomi fish. this is not the place for your stupid
linux propaganda, and as pathetic it is to think you find
some relation between 'hacking' and 'linux', there is
none; so take your OS elsewhere.

as for C syntax, may i *again* suggest to people on
this list to please read "the c programming language".


>
> Can't you make this wiki to _just work_?
>
> --- Shlomi Fish <shlomif@...> wrote:
>
> > Someone has spammed the front page of our wiki:
> >
> > http://xrl.us/euzm
> >
> > I eliminated the spam, and blocked this IP for 100
> > days.
> >
> > It seems the wiki has become very inactive recently,
> > but it still proved very
> > helpful for the Welcome-to-Linux organization.
>
> Hackers-IL != Linux, Welcome or "to". Maybe this
> wiki does not belong to this mailing list?
>
> > Regards,
> >
> > Shlomi Fish
> >
> >
> ---------------------------------------------------------------------
> > Shlomi Fish      shlomif@...
> > Homepage:        http://www.shlomifish.org/
> >
> > Knuth is not God! It took him two days to build the
> > Roman Empire.
> >
>
>
> =====
> --
> o.m.
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>

--- Elad Efrat <elad@...> wrote:

> as a reminder, i suggested long ago that the spammer
> on
> this list is shlomi fish. this is not the place for
> your stupid
> linux propaganda, and as pathetic it is to think you
> find
> some relation between 'hacking' and 'linux', there
> is
> none; so take your OS elsewhere.
>

Elad, _most_ of the audience is Linux people.

> as for C syntax, may i *again* suggest to people on
> this list to please read "the c programming
> language".

No.

>
> >
> > Can't you make this wiki to _just work_?
> >
> > --- Shlomi Fish <shlomif@...> wrote:
> >
> > > Someone has spammed the front page of our wiki:
> > >
> > > http://xrl.us/euzm
> > >
> > > I eliminated the spam, and blocked this IP for
> 100
> > > days.
> > >
> > > It seems the wiki has become very inactive
> recently,
> > > but it still proved very
> > > helpful for the Welcome-to-Linux organization.
> >
> > Hackers-IL != Linux, Welcome or "to". Maybe this
> > wiki does not belong to this mailing list?
> >
> > > Regards,
> > >
> > > Shlomi Fish
> > >
> > >
> >
>
---------------------------------------------------------------------
> > > Shlomi Fish      shlomif@...
> > > Homepage:        http://www.shlomifish.org/
> > >
> > > Knuth is not God! It took him two days to build
> the
> > > Roman Empire.
> > >
> >
> >
> > =====
> > --
> > o.m.
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam
> protection around
> > http://mail.yahoo.com
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
> >
>
>


=====
--
o.m.

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

Elad,
This list is 50% Shlomi Fish's list - he has been the most active
participant in terms of new ideas, discussions, etc.  In practice, a large
part of the definition of the list is by whatever topic Shlomi Fish
writes about.

Hackers-IL was spun off Linux-IL when some people objected to non-Linux
related (but of general hacker interest) topics, and ever since almost
everyone is happy with the distribution of topics between Linux-IL and
Hackers-IL.  This is so even though it is generally recognized that
'Hackers-IL' is a misnomer, which does not really denote the topics
actually discussed in this mailing list.

You are an exception, which sticks out like a sore nail out of a smelly
foot.

If you don't like his style then do all of us a big favor and unsubscribe
from this mailing list.  Obviously, it is not a forum which fits your
trivially imbecile interests, small mind, retarded brain and smelly feet.
                                                 --- Omer

On Tue, 25 Jan 2005, Elad Efrat wrote:

>
> as a reminder, i suggested long ago that the spammer on
> this list is shlomi fish. this is not the place for your stupid
> linux propaganda, and as pathetic it is to think you find
> some relation between 'hacking' and 'linux', there is
> none; so take your OS elsewhere.
                                              --- Omer
My opinions, as expressed in this E-mail message, are mine alone.
They do not represent the official policy of any organization with which
I may be affiliated in any way.
WARNING TO SPAMMERS:  at http://www.zak.co.il/spamwarning.html

On Tuesday 25 January 2005 09:51, omer mussaev wrote:
> Can't you make this wiki to _just work_?
>

This Wiki indeed just works. Everyone can contribute to it by editing any of
the page, history is recorded, etc. However, a Wiki being a world-editable
resource is susceptible to people sabotaging it. There's nothing we can do
about it except blocking everything by passwords, or removing the spam when
it is noticed.

> --- Shlomi Fish <shlomif@...> wrote:
> > Someone has spammed the front page of our wiki:
> >
> > http://xrl.us/euzm
> >
> > I eliminated the spam, and blocked this IP for 100
> > days.
> >
> > It seems the wiki has become very inactive recently,
> > but it still proved very
> > helpful for the Welcome-to-Linux organization.
>
> Hackers-IL != Linux, Welcome or "to". Maybe this
> wiki does not belong to this mailing list?
>

It was not my decision to set up a page for the Welcome-to-Linux coordination
in the Wiki. Someone else set up such a page, and other contributors to the
W2L filled it up with information, and we found it very helpful.

We can easily set up any number of different wikis on the eskimo.iglu.org.il
web-server, if people here feel there should be a separation between the
Hackers-IL endeavours to the Israeli Open-Source Activities. But note that
the Wiki is currently hosted in a server of the Israeli open-source
community, which is under the umbrella of Hamakor.

Regards,

	 Shlomi Fish

---------------------------------------------------------------------
Shlomi Fish      shlomif@...
Homepage:        http://www.shlomifish.org/

Knuth is not God! It took him two days to build the Roman Empire.