Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 9 Feb 2013 02:30:58 +0400
From: Solar Designer <>
Subject: Re: C for dummies

magnum, Jim -

On Fri, Feb 08, 2013 at 02:18:07PM -0600, jfoug wrote:
> From: magnum [] 
> >In common.c we have several lines like this:
> >
> >char itoa16u[16] = "0123456789ABCDEF";
> >
> >Is this a bug or not?

As I found out previously:
In C, no.  In C++, yes.

In OpenCL, I don't know.

> That is a bug.  I have had to make 'changes' for other build environments,
> when taking code from Jtr.  I am not really sure HOW it builds properly in
> Jtr.
> I would much rather see this as 
> const char itoa16u[] = "0123456789ABCDEF";
> OR 
> const char itoa16u[16] =
> {'0','1','2','3','4','5','6','7','8','9','A','B','C','D','E','F'};	
> if we had to maintain sizeof(itoa16u) == 16 for something.

You have to do this (or just let the size be 17) in C++.

> I also do not know why compilers were not complaining. When I cut those
> lines out and put them into other packages, (like the recent wpapcap2john
> project), I did get compiler errors about too many elements, and had to
> change the var declaration.

I guess your other packages are C++.

For example, in crypt_blowfish I actually changed (many years ago) the
declaration of BF_itoa64 to include room for the NUL, to accommodate
people reusing this source file in C++ projects.

However, in passwdqc I deliberately keep the _passwdqc_wordset_4k[]
array without room for the NULs.  Including the NULs would waste 4 KB.

char _passwdqc_wordset_4k[0x1000][6] = {

Obviously, passwdqc builds with many C compilers and works just fine.
It's a feature, not a bug.

As to the addition of const, I fully agree - we should be adding them in
such places.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.