Re: problem with 'strftime' on unix systems

Ok, so I have accepted that strftime on sol10 and sol8 does not support %s :(
Also, the reason why I convert epoch seconds to epoch seconds (which doesn't change anything) is because the format is defined by the user, it can be anything.
Anyway I think I have to solve it like this (I don't have much time)

#!/usr/bin/perl -lw
use strict ;
use POSIX 'strftime' ;

my $fmt ;
$fmt = <STDIN> ;
chomp($fmt) ;

my $time = time() ;

if ( $fmt eq "%s") { print $time }
else { print strftime $fmt, $time }
[download]

Looks OK to me !?!

Thnx
LuCa

Comment on Re: problem with 'strftime' on unix systems Download Code

Replies are listed 'Best First'.
Re^2: problem with 'strftime' on unix systems by gellyfish (Monsignor) on Oct 23, 2006 at 14:08 UTC
You might to want think carefully before passing user supplied input to the format string of `strftime`, the POSIX passes this virtually unchanged to the system `strftime` where there is potential for a 'Format String Vulnerability'. /J\	[reply] [d/l] [select]
Re^2: problem with 'strftime' on unix systems by Anonymous Monk on Oct 23, 2006 at 14:11 UTC
So, where's the user pulling '%s' from then? What if the user gives '%q'? (Not defined for strftime at all) Or '-%s-'? (Also has %s in it). Or '%k' (Which comes from the same package as '%s' comes from)? Or '%P' (A GNU extension, likely to work on Linux, but not a real Unix)? I think you should either say that the user gets whatever his current platform support (meaning that a given format will be the same for different applications on the same platform that use strftime), or you should write your own 'strftime' implementation (meaning that your application behaves the same on different platforms). Both solutions have different advantages when it comes to interoperatbility. But writing your own strftime implementation takes a lot more time, and is unlikely to be as fast as the one from libc. Whether or not that's an issue, I cannot judge.	[reply]