i think that there is one occurence here : doc/elementary_examples_cxx.dox: * @ref location_cxx_example_01

@ProhtMeyhet if there is no such warning on linux, then we can close the task

gcc for Windows, version 9.2.0. I guess that it does not detect that it is defined there :

btw, in code there are also TODO and XXX comments...

"Lastly, you've suggested to use cos rather than cosf before at D10467, jsuya agreed this patch as you can see his comment above. and I agree also."

is this accuracy really needed ?

to mimic Shakespeare:

so, what is the status of this diff ?

install_dir option

btw cosf returns a float, not a double

we can also increase _XOPEN_SOURCE to 700 (http://man7.org/linux/man-pages/man7/feature_test_macros.7.html)

otoh : https://lists.gnu.org/archive/html/autoconf/2010-08/msg00045.html it seems that we should not use __USE_UNIX98

@raster btw, eina_inline_posix_lock.x does:

@raster i've asked the user to export it to CPPFLAGS and issue vanished of course. I will provide a diff

@bu5hm4n i would say in eina as a user should not do extra work. Eina is using some features, it should enable them, imho.

it is garded. adding -D_POSIX_C_SOURCE=200809L in eina.pc (in CFlags) should be sufficient

strlcat does not exist on Windows

option b) is fine for me

Note that elementary makes ephoto unresponsive. Certainly a problem on Windows. I have plenty of this message:

we have plenty of dependencies, so if we can remove some, that would simplify everybody's life

shouldn't this be abandoned and rewritten for meson build system ?

should we add @private to the doc of the functions ?

plane reserved

no, EFL_BUILD is set in config.h, which is also used by binaries. see toplevel meson.build

maybe this should have been detected with a unit test too, no ?

i can't try the test, but i tried the code on a file, and it works with the change mentioned above

i should add a typedef in evil_private.h then. ssize_t does not exist on Windows but SSIZE_T does

why is there a diff for benchmark ?

unmark err as unused

see D9913

mprotect is in evil now. i have to define HAVE_MMAP in evil_mman.h to check if there is no problem. I'll do that today

@stefan_schmidt is this a blocker for 1.23 ?

actually, i've just checked : eina_config.h is generated independantly of eina_config.h.in

I just want to mention that long is a 32 bits type on Windows 64 bits, so you must pay attention at what is done on this platform when using long

after checking, eina_config.h has no EINA_HAS_BUILTIN macro (at least on Windows) with latest git of today(august 31st 2019) with gcc as compiler. Is it normal ?

diff to review : #9542

include mman.h in raw generic module

I don't understand. It's like the other EFL header inclusions which are not part of the lib. Look at all the Eina.h inclusions for examples

i plan to remove sys/mman.h from evil and just a private evil_mman.h (included by evil_private.h)

there is no mman.h on Windows, only in Evil. It's currently exported. I want to make it private in Evil (creates an evil_mman.h, included in evil_private.h), then :

also, there are a lot of files that include sys/mman.h without guarding it with HAVE_SYS_MMAN_H. They must be guarded, right ?

@raster D9493
@bu5hm4n D9494

@raster yes, they are functionnaly equivalent. i've already implemented it on my computer. I'll provide a diff soon for it

@bu5hm4n you added the definition of HAVE_MMAN_H : https://git.enlightenment.org/core/efl.git/commit/header_checks/meson.build?id=46d464e5bfc10398461a33a2256c1c58d509dd1a

@raster VirtualProtect can be used. Also, mprotect exists in FreeBSD since BSD 4.4 [1](quite old), and is in POSIX 2001 [2] and solaris