full-disclosure - linux type definitions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20030414090542.GD29771@irccrew.org>
From: tss at iki.fi (Timo Sirainen)
Subject: linux type definitions

On Mon, Apr 14, 2003 at 07:12:32AM -0000, n d wrote:
> i was wondering why pid_t and size_t are defined as signed integers? im
> not too sure that a process id can be negative. and if strlen returns a
> 16-bit signed integer what would happen if strlen was passed a string with
> a size of 34000?

I don't think pid_t is required to be signed, but a lot of code assumes it
when they compare fork() return value against -1 without casting.

size_t is defined to be unsigned in C99 standard. Some implementations have
defined it as signed, but I'd consider those to be broken. strlen() can't
return a value out of range of size_t, or the implementation is broken
(size_t should have been defined larger).

If you're looking for security holes related to strlen(), I doubt you can
find any real ones. size_t is always defined large enough that your process
runs out of memory before you can overflow it, unless you're still running
some system with segmented memory access (embedded maybe?)