libposix-development Mailing List for libposix (Page 4)
Status: Pre-Alpha
Brought to you by:
hdante
Menu
▾
▴
libposix-development — This list is for those who develop or are willing to develop libposix
You can subscribe to this list here.
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(16) |
Jun
(122) |
Jul
(49) |
Aug
(19) |
Sep
(6) |
Oct
(4) |
Nov
(1) |
Dec
|
|---|
|
From: Tordek <ke...@gm...> - 2009-07-01 03:16:50
|
Signed-off-by: Guillermo O. Freschi <to...@to...>
---
mandatory/include/assert.h | 51
++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 51 insertions(+), 0 deletions(-)
create mode 100644 mandatory/include/assert.h
diff --git a/mandatory/include/assert.h b/mandatory/include/assert.h
new file mode 100644
index 0000000..20c0f8f
--- /dev/null
+++ b/mandatory/include/assert.h
@@ -0,0 +1,51 @@
+/*
+Copyright (c) 2009, Guillermo Oscar Freschi
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
are met:
+
+ * Redistributions of source code must retain the above
copyright notice,
+ this list of conditions and the following disclaimer.
+ * Redistributions in binary form must reproduce the above copyright
+ notice, this list of conditions and the following disclaimer
in the
+ documentation and/or other materials provided with the
distribution.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS"
+AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
TO, THE
+IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE
+ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR
CONTRIBUTORS BE
+LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
BUSINESS
+INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
OF THE
+POSSIBILITY OF SUCH DAMAGE.
+*/
+
+#ifndef _ASSERT_H_INCLUDED_
+#define _ASSERT_H_INCLUDED_
+
+#ifdef NDEBUG
+#define assert(ignore)((void) 0)
+#else
+
+// Temporal hack to show line numbers. Should be removed when
+// printf is fully functional.
+#define _ITOA_(num) #num
+#define _ITOA(num) _ITOA_(num)
+
+#define assert(assertion) \
+ do { \
+ if(!(assertion)) { \
+ puts("Assertion failed in file " __FILE__ ", "\
+ "line " _ITOA(__LINE__) ": "\
+ #assertion); \
+ _Exit(EXIT_FAILURE); \
+ } \
+ } while(0)
+
+#endif /* NDEBUG */
+
+#endif /* _ASSERT_H_INCLUDED_ */
--
1.6.3.3
--
Guillermo O. «Tordek» Freschi. Programador, Escritor, Genio Maligno.
http://tordek.com.ar :: http://twitter.com/tordek
http://www.arcanopedia.com.ar - Juegos de Rol en Argentina
|
|
From: Henrique A. <hd...@gm...> - 2009-07-01 02:17:41
|
Were you able to solve this issue ? 2009/6/26 Kirill A. Shutemov <ki...@sh...>: > On Fri, Jun 26, 2009 at 8:36 PM, Henrique Almeida<hd...@gm...> wrote: >> Can you check /proc/sys/vm/vdso_enabled ? > > I can't reproduce the problem on my home machine. I'll try it on Monday at work. > It looks like local misconfiguration. > > ------------------------------------------------------------------------------ > _______________________________________________ > Libposix-development mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libposix-development > -- Henrique Dante de Almeida hd...@gm... |
|
From: Henrique A. <hd...@gm...> - 2009-07-01 00:07:51
|
Hello. :-) Thanks for the patch. The test file is missing (also it
can go in the "tests" directory, strncpy is a standard function).
2009/6/30 Tordek <ke...@gm...>:
>
> Signed-off-by: Guillermo O. Freschi <to...@to...>
> ---
> CMakeLists.txt | 4 ++++
> mandatory/include/string.h | 1 +
> mandatory/string.c | 20 ++++++++++++++++++++
> 3 files changed, 25 insertions(+), 0 deletions(-)
>
> diff --git a/CMakeLists.txt b/CMakeLists.txt
> index c6be902..435d8d0 100644
> --- a/CMakeLists.txt
> +++ b/CMakeLists.txt
> @@ -85,15 +85,19 @@ add_executable(printf_scanner
> tests/internal/printf_scanner.c
> ${PROJECT_BINARY_DIR}/${runtime_file_name})
> add_executable(printf_parser tests/internal/printf_parser.c
> ${PROJECT_BINARY_DIR}/${runtime_file_name})
> +add_executable(strncpy tests/internal/strncpy.c
> + ${PROJECT_BINARY_DIR}/${runtime_file_name})
> add_test(puts_hello puts_hello)
> add_test(hello hello)
> add_test(printf_scanner printf_scanner)
> add_test(printf_parser printf_parser)
> +add_test(strncpy strncpy)
> target_link_libraries(posix ${LIBPOSIX_COMPILER_STYLE})
> target_link_libraries(hello posix)
> target_link_libraries(puts_hello posix)
> target_link_libraries(printf_scanner posix)
> target_link_libraries(printf_parser posix)
> +target_link_libraries(strncpy posix)
> install(TARGETS posix DESTINATION ${LIBPOSIX_LIBRARY_DIRECTORY})
> install(DIRECTORY ${mandatory_include_path}/
> DESTINATION ${LIBPOSIX_INCLUDE_DIRECTORY})
> diff --git a/mandatory/include/string.h b/mandatory/include/string.h
> index 0c9d517..fe690bd 100644
> --- a/mandatory/include/string.h
> +++ b/mandatory/include/string.h
> @@ -41,5 +41,6 @@ char *strcat(char *restrict, const char *restrict);
> char *strchr(const char *, int);
> int strcmp(const char *, const char *);
> char *strcpy(char *restrict, const char *restrict);
> +char *strncpy(char *restrict s1, const char *restrict s2, size_t n);
>
> #endif /* _STRING_H_DEFINED_ */
> diff --git a/mandatory/string.c b/mandatory/string.c
> index db91b92..fad1f1e 100644
> --- a/mandatory/string.c
> +++ b/mandatory/string.c
> @@ -77,6 +77,26 @@ char *strcat(char *restrict dst, const char
> *restrict src)
> return dst;
> }
>
> +char *strncpy(char *restrict s1, const char *restrict s2, size_t
> size) {
> + char *d = (unsigned char *) s1;
> + char *s = (unsigned char *) s2;
> +
> + while(size--) {
> + *d++ = *s++;
> +
> + if(*s == '\0')
> + break;
> + }
> +
> + size++;
> +
> + while(size--) {
> + *d++ = '\0';
> + }
> +
> + return s1;
> +}
> +
> void *memset(void *ptr, int value, size_t size)
> {
> char *p = (char *)ptr;
> --
> 1.6.3.3
>
>
> --
> Guillermo O. «Tordek» Freschi. Programador, Escritor, Genio Maligno.
> http://tordek.com.ar :: http://twitter.com/tordek
> http://www.arcanopedia.com.ar - Juegos de Rol en Argentina
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Libposix-development mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libposix-development
>
>
--
Henrique Dante de Almeida
hd...@gm...
|
|
From: Tordek <ke...@gm...> - 2009-07-01 00:02:22
|
Signed-off-by: Guillermo O. Freschi <to...@to...>
---
CMakeLists.txt | 4 ++++
mandatory/include/string.h | 1 +
mandatory/string.c | 20 ++++++++++++++++++++
3 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index c6be902..435d8d0 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -85,15 +85,19 @@ add_executable(printf_scanner
tests/internal/printf_scanner.c
${PROJECT_BINARY_DIR}/${runtime_file_name})
add_executable(printf_parser tests/internal/printf_parser.c
${PROJECT_BINARY_DIR}/${runtime_file_name})
+add_executable(strncpy tests/internal/strncpy.c
+ ${PROJECT_BINARY_DIR}/${runtime_file_name})
add_test(puts_hello puts_hello)
add_test(hello hello)
add_test(printf_scanner printf_scanner)
add_test(printf_parser printf_parser)
+add_test(strncpy strncpy)
target_link_libraries(posix ${LIBPOSIX_COMPILER_STYLE})
target_link_libraries(hello posix)
target_link_libraries(puts_hello posix)
target_link_libraries(printf_scanner posix)
target_link_libraries(printf_parser posix)
+target_link_libraries(strncpy posix)
install(TARGETS posix DESTINATION ${LIBPOSIX_LIBRARY_DIRECTORY})
install(DIRECTORY ${mandatory_include_path}/
DESTINATION ${LIBPOSIX_INCLUDE_DIRECTORY})
diff --git a/mandatory/include/string.h b/mandatory/include/string.h
index 0c9d517..fe690bd 100644
--- a/mandatory/include/string.h
+++ b/mandatory/include/string.h
@@ -41,5 +41,6 @@ char *strcat(char *restrict, const char *restrict);
char *strchr(const char *, int);
int strcmp(const char *, const char *);
char *strcpy(char *restrict, const char *restrict);
+char *strncpy(char *restrict s1, const char *restrict s2, size_t n);
#endif /* _STRING_H_DEFINED_ */
diff --git a/mandatory/string.c b/mandatory/string.c
index db91b92..fad1f1e 100644
--- a/mandatory/string.c
+++ b/mandatory/string.c
@@ -77,6 +77,26 @@ char *strcat(char *restrict dst, const char
*restrict src)
return dst;
}
+char *strncpy(char *restrict s1, const char *restrict s2, size_t
size) {
+ char *d = (unsigned char *) s1;
+ char *s = (unsigned char *) s2;
+
+ while(size--) {
+ *d++ = *s++;
+
+ if(*s == '\0')
+ break;
+ }
+
+ size++;
+
+ while(size--) {
+ *d++ = '\0';
+ }
+
+ return s1;
+}
+
void *memset(void *ptr, int value, size_t size)
{
char *p = (char *)ptr;
--
1.6.3.3
--
Guillermo O. «Tordek» Freschi. Programador, Escritor, Genio Maligno.
http://tordek.com.ar :: http://twitter.com/tordek
http://www.arcanopedia.com.ar - Juegos de Rol en Argentina
|
|
From: Henrique A. <hd...@gm...> - 2009-06-30 23:49:47
|
In the beginning of the project we were somewhat lazy with the copyright notices, so I've fully revised them since the initial commit. Now that the license is well defined, let's remember to always insert a copyright notice when editing the files (this is specially targeted at myself :-P). -- Henrique Dante de Almeida hd...@gm... |
|
From: Henrique A. <hd...@gm...> - 2009-06-30 23:03:27
|
The value of EXIT_SUCCESS must be zero, I've changed the constants in stdlib.h to typical values. 2009/6/30 John Haitas <jh...@gm...>: > OK, I'm going to call it a night... will look at it further tomorrow... > > Hope my contributions are of some value. > > Cheers, > John > > On Jun 29, 2009, at 11:50 PM, Henrique Almeida wrote: > >> We can do that in steps. Just assume the "POSIX" locale for now. >> >> 2009/6/30 <jh...@gm...>: >>> Yes, I was looking at that. To properly implement ctype I think we >>> need to >>> implement locale >>> On Mon, Jun 29, 2009 at 10:03 PM, Henrique >>> Almeida<hd...@gm...> wrote: >>>> >>>> I think we can't assume that the character set is ASCII compatible. >>>> We probably could restrict which character sets we'd allow, but >>>> there's at least one Unix vendor/user (IBM) that probably won't >>>> accept >>>> that. A safer implementation is the trivial case 'A': case 'B': case >>>> 'C': etc. (the compiler must optimize those in ASCII systems). Refer >>>> to: >>>> >>>> http://www.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap06.html >>>> >>>> I think the only possible assumptions about the portable character >>>> set are that '0' to '9' are sequential and that '\0' == 0. >>>> >>>> -- >>>> Henrique Dante de Almeida >>>> hd...@gm... >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> _______________________________________________ >>>> Libposix-development mailing list >>>> Lib...@li... >>>> https://lists.sourceforge.net/lists/listinfo/libposix-development >>>> >>> >>> >>> >>> -- >>> John Haitas >>> jh...@gm... >>> >>> >>> ------------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Libposix-development mailing list >>> Lib...@li... >>> https://lists.sourceforge.net/lists/listinfo/libposix-development >>> >>> >> >> >> >> -- >> Henrique Dante de Almeida >> hd...@gm... >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Libposix-development mailing list >> Lib...@li... >> https://lists.sourceforge.net/lists/listinfo/libposix-development > > -- > John Haitas > jh...@gm... > > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Libposix-development mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libposix-development > -- Henrique Dante de Almeida hd...@gm... |
|
From: John H. <jh...@gm...> - 2009-06-30 05:07:07
|
OK, I'm going to call it a night... will look at it further tomorrow... Hope my contributions are of some value. Cheers, John On Jun 29, 2009, at 11:50 PM, Henrique Almeida wrote: > We can do that in steps. Just assume the "POSIX" locale for now. > > 2009/6/30 <jh...@gm...>: >> Yes, I was looking at that. To properly implement ctype I think we >> need to >> implement locale >> On Mon, Jun 29, 2009 at 10:03 PM, Henrique >> Almeida<hd...@gm...> wrote: >>> >>> I think we can't assume that the character set is ASCII compatible. >>> We probably could restrict which character sets we'd allow, but >>> there's at least one Unix vendor/user (IBM) that probably won't >>> accept >>> that. A safer implementation is the trivial case 'A': case 'B': case >>> 'C': etc. (the compiler must optimize those in ASCII systems). Refer >>> to: >>> >>> http://www.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap06.html >>> >>> I think the only possible assumptions about the portable character >>> set are that '0' to '9' are sequential and that '\0' == 0. >>> >>> -- >>> Henrique Dante de Almeida >>> hd...@gm... >>> >>> >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> Libposix-development mailing list >>> Lib...@li... >>> https://lists.sourceforge.net/lists/listinfo/libposix-development >>> >> >> >> >> -- >> John Haitas >> jh...@gm... >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Libposix-development mailing list >> Lib...@li... >> https://lists.sourceforge.net/lists/listinfo/libposix-development >> >> > > > > -- > Henrique Dante de Almeida > hd...@gm... > > ------------------------------------------------------------------------------ > _______________________________________________ > Libposix-development mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libposix-development -- John Haitas jh...@gm... |
|
From: Henrique A. <hd...@gm...> - 2009-06-30 04:51:32
|
We can do that in steps. Just assume the "POSIX" locale for now. 2009/6/30 <jh...@gm...>: > Yes, I was looking at that. To properly implement ctype I think we need to > implement locale > On Mon, Jun 29, 2009 at 10:03 PM, Henrique Almeida<hd...@gm...> wrote: >> >> I think we can't assume that the character set is ASCII compatible. >> We probably could restrict which character sets we'd allow, but >> there's at least one Unix vendor/user (IBM) that probably won't accept >> that. A safer implementation is the trivial case 'A': case 'B': case >> 'C': etc. (the compiler must optimize those in ASCII systems). Refer >> to: >> >> http://www.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap06.html >> >> I think the only possible assumptions about the portable character >> set are that '0' to '9' are sequential and that '\0' == 0. >> >> -- >> Henrique Dante de Almeida >> hd...@gm... >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Libposix-development mailing list >> Lib...@li... >> https://lists.sourceforge.net/lists/listinfo/libposix-development >> > > > > -- > John Haitas > jh...@gm... > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Libposix-development mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libposix-development > > -- Henrique Dante de Almeida hd...@gm... |
|
From: <jh...@gm...> - 2009-06-30 03:17:02
|
Yes, I was looking at that. To properly implement ctype I think we need to implement locale On Mon, Jun 29, 2009 at 10:03 PM, Henrique Almeida<hd...@gm...> wrote: > I think we can't assume that the character set is ASCII compatible. > We probably could restrict which character sets we'd allow, but > there's at least one Unix vendor/user (IBM) that probably won't accept > that. A safer implementation is the trivial case 'A': case 'B': case > 'C': etc. (the compiler must optimize those in ASCII systems). Refer > to: > > http://www.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap06.html > > I think the only possible assumptions about the portable character > set are that '0' to '9' are sequential and that '\0' == 0. > > -- > Henrique Dante de Almeida > hd...@gm... > > ------------------------------------------------------------------------------ > _______________________________________________ > Libposix-development mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libposix-development > -- John Haitas jh...@gm... |
|
From: Henrique A. <hd...@gm...> - 2009-06-30 03:03:53
|
I think we can't assume that the character set is ASCII compatible. We probably could restrict which character sets we'd allow, but there's at least one Unix vendor/user (IBM) that probably won't accept that. A safer implementation is the trivial case 'A': case 'B': case 'C': etc. (the compiler must optimize those in ASCII systems). Refer to: http://www.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap06.html I think the only possible assumptions about the portable character set are that '0' to '9' are sequential and that '\0' == 0. -- Henrique Dante de Almeida hd...@gm... |
|
From: <jh...@gm...> - 2009-06-30 02:49:52
|
Works for me. On Mon, Jun 29, 2009 at 9:36 PM, Henrique Almeida<hd...@gm...> wrote: > I've added test support for CMakeLists.txt. The INSTALL file is now > updated with the new build instructions. Now libposix officially > builds with CMake. Please test. > > -- > Henrique Dante de Almeida > hd...@gm... > > ------------------------------------------------------------------------------ > _______________________________________________ > Libposix-development mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libposix-development > -- John Haitas jh...@gm... |
|
From: <jh...@gm...> - 2009-06-30 02:49:40
|
Works for me. On Mon, Jun 29, 2009 at 9:36 PM, Henrique Almeida<hd...@gm...> wrote: > I've added test support for CMakeLists.txt. The INSTALL file is now > updated with the new build instructions. Now libposix officially > builds with CMake. Please test. > > -- > Henrique Dante de Almeida > hd...@gm... > > ------------------------------------------------------------------------------ > _______________________________________________ > Libposix-development mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libposix-development > -- John Haitas jh...@gm... |
|
From: Henrique A. <hd...@gm...> - 2009-06-30 02:40:24
|
Fixed (included libgcc support library). 2009/6/29 John Haitas <jh...@gm...>: > I fixed the div_t, ldiv_t and lldiv_t definitions. > > I am trying the cmake method and I am getting problems with '__divdi3' > and '__moddi3'. > > Output attached. > > > On Mon, Jun 29, 2009 at 6:33 PM, John Haitas<jh...@gm...> wrote: >> no worries, i've created a problem with div_t, ldiv_t and lldiv_t ... >> working on that right now >> >> On Mon, Jun 29, 2009 at 6:30 PM, Henrique Almeida<hd...@gm...> wrote: >>> Same bug here, I've just noticed that I forgot to update the >>> Makefile, sorry about that. Please try to build with cmake to check >>> that the error disappears. The instructions follow: >>> >>> $ cd .. && mkdir libposix.build && cd libposix.build >>> $ cmake ../libposix >>> $ make >>> >>> I'll deal with the issue in a couple of hours. >>> >>> 2009/6/29 <jh...@gm...>: >>>> Hey guys, >>>> >>>> Is anyone having trouble building libposix in its current state? I am >>>> getting a lot of errors from the printf() implementation. I have tested with >>>> GCC 4.3 and 4.4 (Ubuntu Jaunty and Karmic) I am attaching the output so >>>> y'all can see what I am seeing. >>>> >>>> Any suggestions as to what the problem may be would be very helpful. >>>> >>>> Cheers, >>>> John >>>> >>>> -- >>>> John Haitas >>>> jh...@gm... >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Libposix-development mailing list >>>> Lib...@li... >>>> https://lists.sourceforge.net/lists/listinfo/libposix-development >>>> >>>> >>> >>> >>> >>> -- >>> Henrique Dante de Almeida >>> hd...@gm... >>> >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> Libposix-development mailing list >>> Lib...@li... >>> https://lists.sourceforge.net/lists/listinfo/libposix-development >>> >> >> >> >> -- >> John Haitas >> jh...@gm... >> > > > > -- > John Haitas > jh...@gm... > > ------------------------------------------------------------------------------ > > _______________________________________________ > Libposix-development mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libposix-development > > -- Henrique Dante de Almeida hd...@gm... |
|
From: Henrique A. <hd...@gm...> - 2009-06-30 02:36:51
|
I've added test support for CMakeLists.txt. The INSTALL file is now updated with the new build instructions. Now libposix officially builds with CMake. Please test. -- Henrique Dante de Almeida hd...@gm... |
|
From: John H. <jh...@gm...> - 2009-06-29 23:58:09
|
I fixed the div_t, ldiv_t and lldiv_t definitions. I am trying the cmake method and I am getting problems with '__divdi3' and '__moddi3'. Output attached. On Mon, Jun 29, 2009 at 6:33 PM, John Haitas<jh...@gm...> wrote: > no worries, i've created a problem with div_t, ldiv_t and lldiv_t ... > working on that right now > > On Mon, Jun 29, 2009 at 6:30 PM, Henrique Almeida<hd...@gm...> wrote: >> Same bug here, I've just noticed that I forgot to update the >> Makefile, sorry about that. Please try to build with cmake to check >> that the error disappears. The instructions follow: >> >> $ cd .. && mkdir libposix.build && cd libposix.build >> $ cmake ../libposix >> $ make >> >> I'll deal with the issue in a couple of hours. >> >> 2009/6/29 <jh...@gm...>: >>> Hey guys, >>> >>> Is anyone having trouble building libposix in its current state? I am >>> getting a lot of errors from the printf() implementation. I have tested with >>> GCC 4.3 and 4.4 (Ubuntu Jaunty and Karmic) I am attaching the output so >>> y'all can see what I am seeing. >>> >>> Any suggestions as to what the problem may be would be very helpful. >>> >>> Cheers, >>> John >>> >>> -- >>> John Haitas >>> jh...@gm... >>> >>> >>> ------------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Libposix-development mailing list >>> Lib...@li... >>> https://lists.sourceforge.net/lists/listinfo/libposix-development >>> >>> >> >> >> >> -- >> Henrique Dante de Almeida >> hd...@gm... >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Libposix-development mailing list >> Lib...@li... >> https://lists.sourceforge.net/lists/listinfo/libposix-development >> > > > > -- > John Haitas > jh...@gm... > -- John Haitas jh...@gm... |
|
From: John H. <jh...@gm...> - 2009-06-29 23:34:07
|
no worries, i've created a problem with div_t, ldiv_t and lldiv_t ... working on that right now On Mon, Jun 29, 2009 at 6:30 PM, Henrique Almeida<hd...@gm...> wrote: > Same bug here, I've just noticed that I forgot to update the > Makefile, sorry about that. Please try to build with cmake to check > that the error disappears. The instructions follow: > > $ cd .. && mkdir libposix.build && cd libposix.build > $ cmake ../libposix > $ make > > I'll deal with the issue in a couple of hours. > > 2009/6/29 <jh...@gm...>: >> Hey guys, >> >> Is anyone having trouble building libposix in its current state? I am >> getting a lot of errors from the printf() implementation. I have tested with >> GCC 4.3 and 4.4 (Ubuntu Jaunty and Karmic) I am attaching the output so >> y'all can see what I am seeing. >> >> Any suggestions as to what the problem may be would be very helpful. >> >> Cheers, >> John >> >> -- >> John Haitas >> jh...@gm... >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Libposix-development mailing list >> Lib...@li... >> https://lists.sourceforge.net/lists/listinfo/libposix-development >> >> > > > > -- > Henrique Dante de Almeida > hd...@gm... > > ------------------------------------------------------------------------------ > _______________________________________________ > Libposix-development mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libposix-development > -- John Haitas jh...@gm... |
|
From: Henrique A. <hd...@gm...> - 2009-06-29 23:31:49
|
Same bug here, I've just noticed that I forgot to update the Makefile, sorry about that. Please try to build with cmake to check that the error disappears. The instructions follow: $ cd .. && mkdir libposix.build && cd libposix.build $ cmake ../libposix $ make I'll deal with the issue in a couple of hours. 2009/6/29 <jh...@gm...>: > Hey guys, > > Is anyone having trouble building libposix in its current state? I am > getting a lot of errors from the printf() implementation. I have tested with > GCC 4.3 and 4.4 (Ubuntu Jaunty and Karmic) I am attaching the output so > y'all can see what I am seeing. > > Any suggestions as to what the problem may be would be very helpful. > > Cheers, > John > > -- > John Haitas > jh...@gm... > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Libposix-development mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libposix-development > > -- Henrique Dante de Almeida hd...@gm... |
|
From: <jh...@gm...> - 2009-06-29 23:00:52
|
-std=c99 -Imandatory/include -Icompiler/gcc -Iruntime -Wall -Wextra -g -nostdlib -fPIC -Isystem/linux -Isystem/linux/x86_32 -c mandatory/printf_conversions.c -o output-linux-x86_32/printf_conversions.o In file included from mandatory/printf_conversions.c:25: /usr/include/printf.h:74: error: expected declaration specifiers or â...â before âsize_tâ /usr/include/printf.h:96: error: expected â=â, â,â, â;â, âasmâ or â__attribute__â before âparse_printf_formatâ /usr/include/printf.h:140: error: expected declaration specifiers or â...â before âsize_tâ mandatory/printf_conversions.c:32: error: expected â=â, â,â, â;â, âasmâ or â__attribute__â before âsigned_size_tâ mandatory/printf_conversions.c:38: error: expected â)â before â*â token mandatory/printf_conversions.c:39: error: expected â)â before â*â token mandatory/printf_conversions.c:40: error: expected â)â before â*â token mandatory/printf_conversions.c:41: error: expected â)â before â*â token mandatory/printf_conversions.c:42: error: expected â)â before â*â token mandatory/printf_conversions.c:43: error: expected â)â before â*â token mandatory/printf_conversions.c:44: error: expected â)â before â*â token mandatory/printf_conversions.c:45: error: expected â)â before â*â token mandatory/printf_conversions.c:46: error: expected â)â before â*â token mandatory/printf_conversions.c:48: error: expected declaration specifiers or â...â before âparser_stateâ mandatory/printf_conversions.c:49: error: expected declaration specifiers or â...â before âparser_stateâ mandatory/printf_conversions.c:49: error: expected declaration specifiers or â...â before âtoken_typeâ mandatory/printf_conversions.c:50: error: expected declaration specifiers or â...â before âparser_stateâ mandatory/printf_conversions.c:51: error: expected declaration specifiers or â...â before âparser_stateâ mandatory/printf_conversions.c:52: error: expected declaration specifiers or â...â before âparser_stateâ mandatory/printf_conversions.c:52: error: expected declaration specifiers or â...â before âtoken_typeâ mandatory/printf_conversions.c:53: error: expected declaration specifiers or â...â before âparser_stateâ mandatory/printf_conversions.c:54: error: expected declaration specifiers or â...â before âparser_stateâ mandatory/printf_conversions.c:54: error: expected declaration specifiers or â...â before âtoken_typeâ mandatory/printf_conversions.c:55: error: expected declaration specifiers or â...â before âparser_stateâ mandatory/printf_conversions.c:56: error: expected declaration specifiers or â...â before âparser_stateâ mandatory/printf_conversions.c:58: error: expected â)â before â*â token mandatory/printf_conversions.c:69: error: expected â)â before â*â token mandatory/printf_conversions.c:108: error: expected â)â before â*â token mandatory/printf_conversions.c:146: error: expected â)â before â*â token mandatory/printf_conversions.c:184: error: expected â)â before â*â token mandatory/printf_conversions.c:222: error: expected â)â before â*â token mandatory/printf_conversions.c:260: error: expected â)â before â*â token mandatory/printf_conversions.c:298: error: expected â)â before â*â token mandatory/printf_conversions.c:336: error: expected â)â before â*â token mandatory/printf_conversions.c:397: error: expected â)â before â*â token mandatory/printf_conversions.c:414: error: expected â)â before â*â token mandatory/printf_conversions.c:476: error: expected declaration specifiers or â...â before âparser_stateâ mandatory/printf_conversions.c: In function âoutput_signedâ: mandatory/printf_conversions.c:476: warning: unused parameter âxâ mandatory/printf_conversions.c: At top level: mandatory/printf_conversions.c:479: error: expected declaration specifiers or â...â before âparser_stateâ mandatory/printf_conversions.c:479: error: expected declaration specifiers or â...â before âtoken_typeâ mandatory/printf_conversions.c: In function âoutput_unsignedâ: mandatory/printf_conversions.c:479: warning: unused parameter âtxâ mandatory/printf_conversions.c: At top level: mandatory/printf_conversions.c:482: error: expected declaration specifiers or â...â before âparser_stateâ mandatory/printf_conversions.c: In function âoutput_wint_tâ: mandatory/printf_conversions.c:482: warning: unused parameter âwiâ mandatory/printf_conversions.c: At top level: mandatory/printf_conversions.c:486: error: expected declaration specifiers or â...â before âparser_stateâ mandatory/printf_conversions.c: In function âoutput_wchar_t_pointerâ: mandatory/printf_conversions.c:486: warning: unused parameter âwcâ mandatory/printf_conversions.c: At top level: mandatory/printf_conversions.c:489: error: expected declaration specifiers or â...â before âparser_stateâ mandatory/printf_conversions.c:489: error: expected declaration specifiers or â...â before âtoken_typeâ mandatory/printf_conversions.c: In function âoutput_doubleâ: mandatory/printf_conversions.c:489: warning: unused parameter âxâ mandatory/printf_conversions.c: At top level: mandatory/printf_conversions.c:492: error: expected declaration specifiers or â...â before âparser_stateâ mandatory/printf_conversions.c: In function âoutput_charâ: mandatory/printf_conversions.c:492: warning: unused parameter âcâ mandatory/printf_conversions.c: At top level: mandatory/printf_conversions.c:495: error: expected declaration specifiers or â...â before âparser_stateâ mandatory/printf_conversions.c:495: error: expected declaration specifiers or â...â before âtoken_typeâ mandatory/printf_conversions.c: In function âoutput_long_doubleâ: mandatory/printf_conversions.c:495: warning: unused parameter âxâ mandatory/printf_conversions.c: At top level: mandatory/printf_conversions.c:498: error: expected declaration specifiers or â...â before âparser_stateâ mandatory/printf_conversions.c: In function âoutput_char_pointerâ: mandatory/printf_conversions.c:498: warning: unused parameter âsâ mandatory/printf_conversions.c: At top level: mandatory/printf_conversions.c:501: error: expected declaration specifiers or â...â before âparser_stateâ mandatory/printf_conversions.c: In function âoutput_void_pointerâ: mandatory/printf_conversions.c:501: warning: unused parameter âpâ make: *** [output-linux-x86_32/printf_conversions.o] Error 1 |
|
From: Henrique A. <hd...@gm...> - 2009-06-29 14:31:43
|
It could be used in the short term, but alloca is not present in the standard. According to glibc docs, it's a BSD extension. 2009/6/28 Chris Forbes <ch...@fa...>: > Henrique: > >> require a working malloc implementation > > I assume you'd be able to allocate that stuff locally in your own stack > frame with alloca(), in lieu of having a real allocator? > > -- Chris > > -----Original Message----- > From: Henrique Almeida [mailto:hd...@gm...] > Sent: Monday, 29 June 2009 12:14 p.m. > To: lib...@li... > Subject: Re: [libposix-development] printf parser > > We have to make them too. Lots of them. While printf is not ready, > the two programs cited are unit tests for the parser and scanner. I've > put them in the "tests/internal" directory since they are > implementation details. Also we're missing support for tests in our > CMakeLists.txt (ie "make test"). After that the CMake build will be > complete. > > 2009/6/28 Kirill A. Shutemov <ki...@sh...>: >> On Sun, Jun 28, 2009 at 6:41 PM, Henrique Almeida<hd...@gm...> wrote: >>> I'm approaching a complete printf implementation, and I've just >>> updated a printf parser to the repository, which is already in an >>> advanced state. It's able to parse non trivial strings, like "e %-2ld >>> f %0#'133.45Lg g %+.hhX i\n". The actual output functions >>> (output_unsigned, output_double, etc.) are still missing, so it >>> doesn't print anything yet, but I'll start writing those soon. Also >>> missing are dealing with "numbered arguments" (things like "%2$d %1$s >>> %3$g", they allow out of order argument passing), which are harder and >>> require a working malloc implementation. >>> >>> Please run the tests "printf_parser" and "printf_scanner" and check >>> that they don't crash or give weird results. printf_scanner should >>> return zero and printf_parser should have the following result at the >>> moment: >>> >>> abcd >>> e f g i >>> >>> I expect to finish this until the middle of the week, so that we have >>> a nearly complete printf. >> >> What about unit tests? >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Libposix-development mailing list >> Lib...@li... >> https://lists.sourceforge.net/lists/listinfo/libposix-development >> > > > > -- > Henrique Dante de Almeida > hd...@gm... > > ------------------------------------------------------------------------------ > _______________________________________________ > Libposix-development mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libposix-development > ------------------------------------------------------------------------------ > _______________________________________________ > Libposix-development mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libposix-development > -- Henrique Dante de Almeida hd...@gm... |
|
From: Henrique A. <hd...@gm...> - 2009-06-29 14:26:08
|
2009/6/29 Kirill A. Shutemov <ki...@sh...>: > On Sat, Jun 27, 2009 at 11:58 PM, Henrique Almeida<hd...@gm...> wrote: >> It didn't work again, but this time because I have changed >> CMakeLists.txt, so I just rewrote the patch and applied locally. I'll >> update it with my latest changes when my repository is in a sane >> state. > > How do you apply the patch? I'm saving the e-mail and using git am. > > Can you make size limit of message in the mail list higher? It's up to 90 KB now > > ------------------------------------------------------------------------------ > _______________________________________________ > Libposix-development mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libposix-development > -- Henrique Dante de Almeida hd...@gm... |
|
From: Kirill A. S. <ki...@sh...> - 2009-06-29 06:28:58
|
On Mon, Jun 29, 2009 at 3:14 AM, Henrique Almeida<hd...@gm...> wrote: > We have to make them too. Lots of them. While printf is not ready, > the two programs cited are unit tests for the parser and scanner. I've > put them in the "tests/internal" directory since they are > implementation details. Also we're missing support for tests in our > CMakeLists.txt (ie "make test"). After that the CMake build will be > complete. I think the Test-Driven Development is right thing for project like this. |
|
From: Kirill A. S. <ki...@sh...> - 2009-06-29 06:21:29
|
On Sat, Jun 27, 2009 at 11:58 PM, Henrique Almeida<hd...@gm...> wrote: > It didn't work again, but this time because I have changed > CMakeLists.txt, so I just rewrote the patch and applied locally. I'll > update it with my latest changes when my repository is in a sane > state. How do you apply the patch? Can you make size limit of message in the mail list higher? |
|
From: Chris F. <ch...@fa...> - 2009-06-29 02:21:59
|
Henrique: > require a working malloc implementation I assume you'd be able to allocate that stuff locally in your own stack frame with alloca(), in lieu of having a real allocator? -- Chris -----Original Message----- From: Henrique Almeida [mailto:hd...@gm...] Sent: Monday, 29 June 2009 12:14 p.m. To: lib...@li... Subject: Re: [libposix-development] printf parser We have to make them too. Lots of them. While printf is not ready, the two programs cited are unit tests for the parser and scanner. I've put them in the "tests/internal" directory since they are implementation details. Also we're missing support for tests in our CMakeLists.txt (ie "make test"). After that the CMake build will be complete. 2009/6/28 Kirill A. Shutemov <ki...@sh...>: > On Sun, Jun 28, 2009 at 6:41 PM, Henrique Almeida<hd...@gm...> wrote: >> I'm approaching a complete printf implementation, and I've just >> updated a printf parser to the repository, which is already in an >> advanced state. It's able to parse non trivial strings, like "e %-2ld >> f %0#'133.45Lg g %+.hhX i\n". The actual output functions >> (output_unsigned, output_double, etc.) are still missing, so it >> doesn't print anything yet, but I'll start writing those soon. Also >> missing are dealing with "numbered arguments" (things like "%2$d %1$s >> %3$g", they allow out of order argument passing), which are harder and >> require a working malloc implementation. >> >> Please run the tests "printf_parser" and "printf_scanner" and check >> that they don't crash or give weird results. printf_scanner should >> return zero and printf_parser should have the following result at the >> moment: >> >> abcd >> e f g i >> >> I expect to finish this until the middle of the week, so that we have >> a nearly complete printf. > > What about unit tests? > > ------------------------------------------------------------------------------ > _______________________________________________ > Libposix-development mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libposix-development > -- Henrique Dante de Almeida hd...@gm... ------------------------------------------------------------------------------ _______________________________________________ Libposix-development mailing list Lib...@li... https://lists.sourceforge.net/lists/listinfo/libposix-development |
|
From: Henrique A. <hd...@gm...> - 2009-06-29 02:19:05
|
We have to make them too. Lots of them. While printf is not ready, the two programs cited are unit tests for the parser and scanner. I've put them in the "tests/internal" directory since they are implementation details. Also we're missing support for tests in our CMakeLists.txt (ie "make test"). After that the CMake build will be complete. 2009/6/28 Kirill A. Shutemov <ki...@sh...>: > On Sun, Jun 28, 2009 at 6:41 PM, Henrique Almeida<hd...@gm...> wrote: >> I'm approaching a complete printf implementation, and I've just >> updated a printf parser to the repository, which is already in an >> advanced state. It's able to parse non trivial strings, like "e %-2ld >> f %0#'133.45Lg g %+.hhX i\n". The actual output functions >> (output_unsigned, output_double, etc.) are still missing, so it >> doesn't print anything yet, but I'll start writing those soon. Also >> missing are dealing with "numbered arguments" (things like "%2$d %1$s >> %3$g", they allow out of order argument passing), which are harder and >> require a working malloc implementation. >> >> Please run the tests "printf_parser" and "printf_scanner" and check >> that they don't crash or give weird results. printf_scanner should >> return zero and printf_parser should have the following result at the >> moment: >> >> abcd >> e f g i >> >> I expect to finish this until the middle of the week, so that we have >> a nearly complete printf. > > What about unit tests? > > ------------------------------------------------------------------------------ > _______________________________________________ > Libposix-development mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libposix-development > -- Henrique Dante de Almeida hd...@gm... |
|
From: Kirill A. S. <ki...@sh...> - 2009-06-28 18:50:07
|
On Sun, Jun 28, 2009 at 6:41 PM, Henrique Almeida<hd...@gm...> wrote: > I'm approaching a complete printf implementation, and I've just > updated a printf parser to the repository, which is already in an > advanced state. It's able to parse non trivial strings, like "e %-2ld > f %0#'133.45Lg g %+.hhX i\n". The actual output functions > (output_unsigned, output_double, etc.) are still missing, so it > doesn't print anything yet, but I'll start writing those soon. Also > missing are dealing with "numbered arguments" (things like "%2$d %1$s > %3$g", they allow out of order argument passing), which are harder and > require a working malloc implementation. > > Please run the tests "printf_parser" and "printf_scanner" and check > that they don't crash or give weird results. printf_scanner should > return zero and printf_parser should have the following result at the > moment: > > abcd > e f g i > > I expect to finish this until the middle of the week, so that we have > a nearly complete printf. What about unit tests? |
