Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 30 Jul 2013 05:53:28 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Daniel's weekly report #7

Daniel, Lukas -

On Mon, Jul 29, 2013 at 05:01:33PM +0200, D?niel Bali wrote:
> 2013/7/24 Solar Designer <solar@...nwall.com>
> > > Accomplishments:
> > > 1. Added support for user-defined formats
> >
> > What are these?  Any example?
> 
> Uhh, I meant user-defined aliases here. Don't know why I wrote "format", it
> makes no sense. An example for aliases would be:
> 
> #define result v7
> v_mov_b32 result, 2

Here's the corresponding commit:

https://github.com/balidani/gcnasm/commit/9adcd876b389d4296f2f217577bd95906142478a

Do we really need this?  I think that for any serious use we'd be
passing our source code through cpp, which includes more complete macro
support.  I don't mind having this functionality in, though.

Speaking of your C code, instead of the calloc() + strncpy(), you may
use strdup().  strncpy() is very rarely the best choice; I suggest that
you only use it when you need its NUL padding feature.  You're misusing
strncpy() for a possibly slower alternative to memcpy() - really, you
tell it exactly how many chars to copy and don't give it a chance to do
anything else anyway.  In cases when you do need to have the copying
limited to the target buffer size (not the case here), you may use e.g.
this trick:

dst[0] = '\0';
strncat(dst, src, sizeof(dst) - 1);

Note that strncat() guarantees NUL termination, and does not do the
usually unnecessary NUL padding (which strncpy() does).

Also, ctype macros such as toupper() are only defined to work on "int",
so using them on "char" is potentially problematic (although many libc's
include a workaround for this common misuse).  For proper use, you'd
cast your "char" to "unsigned char" and only then to "int" (one of these
can be implied, such as via an assignment).

Alexander

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ